{"action":"created","issue":{"url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/48","repository_url":"https://api.github.com/repos/orbs-network/orbs-spec","labels_url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/48/labels{/name}","comments_url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/48/comments","events_url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/48/events","html_url":"https://github.com/orbs-network/orbs-spec/issues/48","id":340731642,"node_id":"MDU6SXNzdWUzNDA3MzE2NDI=","number":48,"title":"Merkle tree calculation in VM","user":{"login":"ronnno","id":15799888,"node_id":"MDQ6VXNlcjE1Nzk5ODg4","avatar_url":"https://avatars3.githubusercontent.com/u/15799888?v=4","gravatar_id":"","url":"https://api.github.com/users/ronnno","html_url":"https://github.com/ronnno","followers_url":"https://api.github.com/users/ronnno/followers","following_url":"https://api.github.com/users/ronnno/following{/other_user}","gists_url":"https://api.github.com/users/ronnno/gists{/gist_id}","starred_url":"https://api.github.com/users/ronnno/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ronnno/subscriptions","organizations_url":"https://api.github.com/users/ronnno/orgs","repos_url":"https://api.github.com/users/ronnno/repos","events_url":"https://api.github.com/users/ronnno/events{/privacy}","received_events_url":"https://api.github.com/users/ronnno/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"OdedWx","id":37261532,"node_id":"MDQ6VXNlcjM3MjYxNTMy","avatar_url":"https://avatars3.githubusercontent.com/u/37261532?v=4","gravatar_id":"","url":"https://api.github.com/users/OdedWx","html_url":"https://github.com/OdedWx","followers_url":"https://api.github.com/users/OdedWx/followers","following_url":"https://api.github.com/users/OdedWx/following{/other_user}","gists_url":"https://api.github.com/users/OdedWx/gists{/gist_id}","starred_url":"https://api.github.com/users/OdedWx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OdedWx/subscriptions","organizations_url":"https://api.github.com/users/OdedWx/orgs","repos_url":"https://api.github.com/users/OdedWx/repos","events_url":"https://api.github.com/users/OdedWx/events{/privacy}","received_events_url":"https://api.github.com/users/OdedWx/received_events","type":"User","site_admin":false},"assignees":[{"login":"OdedWx","id":37261532,"node_id":"MDQ6VXNlcjM3MjYxNTMy","avatar_url":"https://avatars3.githubusercontent.com/u/37261532?v=4","gravatar_id":"","url":"https://api.github.com/users/OdedWx","html_url":"https://github.com/OdedWx","followers_url":"https://api.github.com/users/OdedWx/followers","following_url":"https://api.github.com/users/OdedWx/following{/other_user}","gists_url":"https://api.github.com/users/OdedWx/gists{/gist_id}","starred_url":"https://api.github.com/users/OdedWx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OdedWx/subscriptions","organizations_url":"https://api.github.com/users/OdedWx/orgs","repos_url":"https://api.github.com/users/OdedWx/repos","events_url":"https://api.github.com/users/OdedWx/events{/privacy}","received_events_url":"https://api.github.com/users/OdedWx/received_events","type":"User","site_admin":false}],"milestone":null,"comments":0,"created_at":"2018-07-12T17:34:32Z","updated_at":"2018-10-21T12:51:14Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Is it worthwhile to let the VM output a Merkle tree diff (including the merkle root) as well as state diff in the process of preparing a new block?\r\n\r\npros:\r\n\r\n- VM may have better CPU resources\r\n- VM may often get state before changing it (can we estimate how often?). so if this state is returned with the Merkle proof there are no additional API calls.\r\n- This allows us to embed the most recent Merkle Root in any proposed block rather than only the previous block. \r\n\r\ncons:\r\n- For new values, and for state changes that are not preceded by a get (override or increment) we will still have to make a \"get\" call against state storage to obtain the Merkle proof for these new items. This however may be condensed to a single round trip in a batch \"get\" operation for any state entry that changes and was not read during execution. \r\n- VM will be responsible for Merkle proof construction and this will not be provided by the state storage.\r\n\r\nOptimization:\r\n- to address concern of slowing down transaction processing due to the need to fetch merkle proofs (multiple IOs), we can use this strategy: when the VM needs a value to process, it can receive it without the proof, at which point, the state storage is signalled load the proof in the background. The same would happen when we add a new state entry or write without a prior read. All these background operations may be processed under one context, and a combined proof for the entire state diff will be collected during execution and retrieved from memory once the processing is done. The only added cost for block creation time is the CPU work needed to update the subset Merkle tree once processing is complete.\r\n- (TBD?) Moreover, when a block is propagated in the network is is also possible to transmit the (signed) merkle tree diff along with the block to reduce overall CPU load in the network. \r\n\r\n"},"comment":{"url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/comments/431666178","html_url":"https://github.com/orbs-network/orbs-spec/issues/48#issuecomment-431666178","issue_url":"https://api.github.com/repos/orbs-network/orbs-spec/issues/48","id":431666178,"node_id":"MDEyOklzc3VlQ29tbWVudDQzMTY2NjE3OA==","user":{"login":"OdedWx","id":37261532,"node_id":"MDQ6VXNlcjM3MjYxNTMy","avatar_url":"https://avatars3.githubusercontent.com/u/37261532?v=4","gravatar_id":"","url":"https://api.github.com/users/OdedWx","html_url":"https://github.com/OdedWx","followers_url":"https://api.github.com/users/OdedWx/followers","following_url":"https://api.github.com/users/OdedWx/following{/other_user}","gists_url":"https://api.github.com/users/OdedWx/gists{/gist_id}","starred_url":"https://api.github.com/users/OdedWx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OdedWx/subscriptions","organizations_url":"https://api.github.com/users/OdedWx/orgs","repos_url":"https://api.github.com/users/OdedWx/repos","events_url":"https://api.github.com/users/OdedWx/events{/privacy}","received_events_url":"https://api.github.com/users/OdedWx/received_events","type":"User","site_admin":false},"created_at":"2018-10-21T12:51:14Z","updated_at":"2018-10-21T12:51:14Z","author_association":"CONTRIBUTOR","body":"Proposal:\r\n1. Modify the interface to: {contract_name, address}\r\n  a. address instead of key\r\n  b. the state storage is unaware of the key.\r\n2. address = hash(%{contract_name, key})\r\n3. Even though the address is unique across contracts, the state is managed per contract (allowing to delete / copy on upgrade)\r\n4. Hash (address length): SHA256 (32B)\r\nDiscussion: TODO\r\n  a. Length extension attack - 2 hash functions.\r\n      RIPEMD160 is often used after SHA256 to prevent length extension attack: derive H(m||x) from H(m) \r\n      without knowing x. This should not a problem for the state storage where the data is public. \r\n  b. Consider LSB20B(SHA256) to reduce the size to 20B\r\n5. Future feature - add a merkle hash table variable type, allowing to store smart contract data under a separate merkle tree.\r\n"}}
{"actor":{"display_login":"OdedWx"}}