These are chat archives for ethereum/ecosystem-standards

29th
Feb 2016
Viktor Trón
@zelig
Feb 29 2016 05:11
Hey @void4
Viktor Trón
@zelig
Feb 29 2016 05:18
there is a already a quasi standard for this. A json file spit out by the solidity compiler
the intended use of this is described in the frontier guide (look for contract info) https://ethereum.gitbooks.io/frontier-guide/content/contract_info.html
This will most likely be elaborated on very soon, and expected to release together with the new namereg
void4
@void4
Feb 29 2016 07:52

@zelig: Yes, this is really cool :)
This information could simply be appended to another JSON object describing the offchain (p2p/network) endpoint metadata. In the case of slock.it, for example, they could be a set of identity addressed, authenticated HTTP endpoints. There, a common format may not be necessary because the service could have its own dapp and the devices offer homogenous interfaces. But even more futuristic stuff such as

  • autonomous service discovery
  • service marketplaces
  • diverse trust and payment methods

across a variety of devices and interfaces will require a universal format.

So for example, if I want to offer live temperature sensor data in exchange for Ether/subcurrency payments, then the specific configuration would have to be documented somewhere. This could be, for example, a "payto:ethereum" link to an address of a contract that implements some transaction model, together with the offchain API documentation.

I hope this makes sense.

Viktor Trón
@zelig
Feb 29 2016 09:34
I dont understand the actual example though. and generally think such cases are not at all ready for standardisation. go on devise practical ways and people either follow or not
void4
@void4
Feb 29 2016 10:29

So, in the case of slock.it, it probably wouldn't be desirable to do all communication on-chain, for privacy reasons alone. Instead, when the user is in the vicinity of the lock he can communicate directly with it (e.g. with Wifi/Bluetooth/NFC) and access an API (over HTTP/pubsub/Whisper/...) to open/close the lock. This has the advantage that the user does not necessarily have to be online, only the device would have to sync with the blockchain - which is only used for functionality that requires consensus, for example exclusive control over the lock, payments and registration.

So you have

  • the owners identity
  • the service/device identity
  • a contract representing the device, referencing both identities
  • a service descriptor file published under the IPNS root of the device identity

A program wanting to use the device will first fetch the service descriptor from Swarm, then, if required, look up and verify the contract on the blockchain and then interact with the API and/or the contract.

Related: Interestingly, Greg Meredith, who presented Monadic Design Patterns for the Blockchain at DEVCON1 is listed as one of the authors of WSDL. Because he describes it as a "train wreck" (http://www.biosimilarity.com/about.html) it would be interesting to know if there are any good alternatives.
ChrisForrester
@psionic81
Feb 29 2016 15:37
I’m sort of curious about the bytecode itself.. I’m not sure it’s necessary to have on the main blockchain itself. As long as an indexed dictionary exists that has all of the programs that have ever been sent out over the network, this dictionary could be transferred through something like ipfs.
RJ Catalano
@VoR0220
Feb 29 2016 19:51
How do you figure that the byte code itself is not necessary on the blockchain?
ChrisForrester
@psionic81
Feb 29 2016 19:59
the code inside of the indexed dictionary could be what is used instead of what is storing it on the blockchain directly.
RJ Catalano
@VoR0220
Feb 29 2016 20:00
Then how would you verify that it was executed?
ChrisForrester
@psionic81
Feb 29 2016 20:00
<using indexed dictionary with hash 0xeia09s9> <run program 00100234> <with data [databytes]>
RJ Catalano
@VoR0220
Feb 29 2016 20:01
Mmmm...maybe. But I'm not sure.
Would certainly cut the bloat if done right.
ChrisForrester
@psionic81
Feb 29 2016 20:23

a few things.. removes bloat, transmission lowered, propagation and synchronization. also the ethereum code itself could be in index 0->10000, which would be:

<using ethereum codebase 00012> <using indexed dictionary with hash 0xeia09s9> <run program 00110534> <with program constants [jsonconstantsbytes]> <with data [databytes]>

after the block is finalized, even the data could be moved into another indexed dictionary.
RJ Catalano
@VoR0220
Feb 29 2016 20:28
interesting proposal.
Perhaps you should make an EIP?
ChrisForrester
@psionic81
Feb 29 2016 20:41
talk is cheap :) I’d like to understand the fundamentals of the system designs and comprehend how to code it before making any fundamental proposals.
I need some more mathematician friends lol
RJ Catalano
@VoR0220
Feb 29 2016 20:42
seems you have a decent enough handling of it to make a suggestion. Just throw it out there. See if it gets traction.
ChrisForrester
@psionic81
Feb 29 2016 20:42

"build a smart contract with a run-only-once clause.

the contract is formed with metadata specifying a specific once-only signature, and that contract being concluded is removed from the ability to be called again.

similarly, said contracts can be reloaded with a specific token, that token allowing a specific usage parameter as specified in the contract. said tokens are worth certain values, and that contract throws unless those specific values are checked against.

this allows for a contract to have a specific ethereum balance and to spend it running function calls to middleware platforms, without being subject to run-of-service attacks where that contract could be asked to provide for too many service calls from specific other contracts.

those other tokens would be produced in an "alternative fuel" methodology, where that fuel is purchased from another contract for ethereum, and providers of a specific key can manufacture the "alternative fuel" at whim.

this could be seen as a means of bypassing a free for all ownership of smart contracts, whereupon unless said contract was replicated with a different fuel, it wouldn't function with the same resistance to run-of-service attacks.

thus that means another method of "alternative fuel" collection or another exact clone of the original fuel contract, whereupon smart usage of hierarchal branches of associated functions could lead to instant modification of a "free call tree" across all associated functions, whereupon all other cloned branches would impose a much steeper transaction cost.

it should be possible as well to virtualize the function database. if the data exists, contracts could access a data store, function call that data store in memory, and return the result."

is my own research blurb. maybe I’ll make a blog eventually with all of my sky pie ideas.
Alex Beregszaszi
@axic
Feb 29 2016 20:44
@psionic81 @VoR0220 fyi IPFS uses the hash of the content as a key, therefore you could just store the code hash and that could be retrieved from IPFS - however this must have its own appropriate gas cost as it could be expensive on the miner (i.e. IPFS can be very slow so having a local cache would be useful and therefore a cost)
and eventually I’m not sure if its a saving at all
ChrisForrester
@psionic81
Feb 29 2016 20:46
@axic it should be the case that each miner is constantly updating the indexed dictionary with a differential stream, and only reading into memory the portions that are used most often. like a gigantic zip file if they had cache optimization fully functional.
Alex Beregszaszi
@axic
Feb 29 2016 20:48
in essence what you are proposing is separating the current storage fee (well storage fee of the contract code itself is part of the contract creation gas) into two options:
1) cached code (paying for being in the cache);
2) cold loaded code (paying for loading from slow storage, i.e. IPFS or anything else)
ChrisForrester
@psionic81
Feb 29 2016 20:48
similarly, and talking with some friends about it, it would seem that if we reorganized the most-used functions every once in a proverbial blue moon (equivalent of a git-mv for the differential stream), we could transmit the index of the function with a 5-20 bit transmission cost instead of the ~60 bits of the total indexed dictionary space.
@axic could be. I was more interested in the transmittion cost instead of the storage.. since the storage is synched constantly I’d have guessed that there would be a slow drip of differential data through ipfs. given that function definitions (as per ideals of being able to compile bytecode into circuit & sub circuit definitions and run a graph isomorphism check on them) will be updated way more slowly than raw data.
Alex Beregszaszi
@axic
Feb 29 2016 20:51
what do you mean by transmission cost here?
ChrisForrester
@psionic81
Feb 29 2016 20:54
<run program 9534>

<using ethereum codebase 00012>
could be assumed if it was only changed at fixed intervals

<using indexed dictionary with hash 0xeia09s9>
could be assumed to be rationally already defined if the contract and subcontract that calls were defined in a confirmed block.

if they tried to use a contract that wasnt associated with the indexed dictionary’s associated store (“program 002415659 doesn’t exist”), they would stall since the ipfs drip had not reached the node, whereupon that node could ask another that was functioning as a super-node (via metrics, uptime, n-star ratings for honesty) what exactly that program’s bytecode was.
Alex Beregszaszi
@axic
Feb 29 2016 21:00
i think at the moment contract code is immutable
ChrisForrester
@psionic81
Feb 29 2016 21:00
which it would be in the indexed dictionary as well.
there could be a greater (smarter) separation of constants and actual circuit logic though.
Alex Beregszaszi
@axic
Feb 29 2016 21:00
all that is in a fast tree storage (merkle-patricia trie)
ChrisForrester
@psionic81
Feb 29 2016 21:01
as always, it’s easiest to accomplish this conceptual mode by considering “for each bit that needs to be transmitted, add 25 seconds of latency”.
slothometry.
Alex Beregszaszi
@axic
Feb 29 2016 21:02
i dont think i fully get you, but contract code is not transmitted at each transaction, only when it is deployed
ChrisForrester
@psionic81
Feb 29 2016 21:04
I’m wondering why you’d be pointing at “cold storage” code then.
from what I understand the database will look much the same, except you cannot reorganize the blockchain to identify the most accessed code in fewer bytes.
similarly, there is no check for duplicate functions if you were to deploy a copy of a contract
ChrisForrester
@psionic81
Feb 29 2016 21:10
I’d like it to go a few steps further and decompose the contract into a form that is the most granular representation possible, and run graph isomorphism checks on that form’s granular components
so even the initial storage and the associated transmitted data, is minimized to it’s absolute smallest lossless representation.
Alex Beregszaszi
@axic
Feb 29 2016 21:14
basically that would be a brand new storage structure for the contracts
ChrisForrester
@psionic81
Feb 29 2016 21:16
new storage structure for code period from what I understand.. the math required to do the decomposition has only existed for a few months.

breaking down a circuit diagram into components:
http://www.wired.com/2015/12/outsiders-crack-a-50-year-old-math-problem/

then measure and attribute by relative "novelty":
http://www.wired.com/2015/12/landmark-algorithm-breaks-30-year-impasse/

Alex Beregszaszi
@axic
Feb 29 2016 21:18
well a dumb form of that would be building a huffman code table or lz dictionary of frequently used code segments
that of course has no understanding of the code
ChrisForrester
@psionic81
Feb 29 2016 21:19
I would guess that the current blockchain is at least as good as that. I’d be surprised to hear that it’s stored uncompressed on disk.
void4
@void4
Feb 29 2016 23:19
@zelig: See my previous message & this: https://gist.github.com/void4/d0389f8d3be526e99130 :)
void4
@void4
Feb 29 2016 23:37
This file would be published under /ipns/<serviceaddr> (IPNS root of that identity). The service address could be referred to by other contracts, by registries for example.
The contract info is simply what is returned by admin.saveInfo()