{"action":"opened","issue":{"url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/71","repository_url":"https://api.github.com/repos/ethereum/eth2.0-specs","labels_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/71/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/71/comments","events_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/71/events","html_url":"https://github.com/ethereum/eth2.0-specs/issues/71","id":369351676,"node_id":"MDU6SXNzdWUzNjkzNTE2NzY=","number":71,"title":"A proposal for chain initialization, main chain block inclusion, and deposit processing","user":{"login":"vbuterin","id":2230894,"node_id":"MDQ6VXNlcjIyMzA4OTQ=","avatar_url":"https://avatars1.githubusercontent.com/u/2230894?v=4","gravatar_id":"","url":"https://api.github.com/users/vbuterin","html_url":"https://github.com/vbuterin","followers_url":"https://api.github.com/users/vbuterin/followers","following_url":"https://api.github.com/users/vbuterin/following{/other_user}","gists_url":"https://api.github.com/users/vbuterin/gists{/gist_id}","starred_url":"https://api.github.com/users/vbuterin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vbuterin/subscriptions","organizations_url":"https://api.github.com/users/vbuterin/orgs","repos_url":"https://api.github.com/users/vbuterin/repos","events_url":"https://api.github.com/users/vbuterin/events{/privacy}","received_events_url":"https://api.github.com/users/vbuterin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-12T00:09:29Z","updated_at":"2018-10-12T00:09:29Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"### On-chain contract\r\n\r\nWe create a deposit contract on the blockchain, with roughly the following code:\r\n\r\n```python\r\nHashChainValue: event({prev_tip: bytes32, data: bytes[300]})\r\nChainStart: event({hash_chain_tip: bytes32, time: timestamp})\r\n\r\nhash_chain_tip: public(bytes32)\r\ntotal_deposit_count: int128\r\n\r\n@payable\r\n@public\r\ndef deposit(data: bytes[300]):\r\n    assert msg.value == as_wei_value(32, \"ether\")\r\n    log.HashChainValue(self.hash_chain_tip, data)\r\n    self.total_deposit_count += 1\r\n    self.hash_chain_tip = sha3(concat(self.hash_chain_tip, data))\r\n    if self.total_deposit_count == 10000:\r\n        log.ChainStart(self.hash_chain_tip, block.timestamp)\r\n```\r\n\r\nWhen a user wishes to move their ETH from the 1.0 chain to the 2.0 chain, they should call the `deposit` function, sending along 32 ETH and providing as `data` a SimpleSerialize'd object with the following arguments (in order):\r\n\r\n* `pubkey`: int256\r\n* `proof_of_possession`: [int256]\r\n* `withdrawal_shard`: int64\r\n* `withdrawal_address`: bytes20\r\n* `randao_commitment`: hash32\r\n\r\nIf they wish to deposit more than 32 ETH, they would need to make multiple calls.\r\n\r\n[Governance note: when publishing the final version of this contract, it may be desirable to issue some kind of formal EIP that \"enshrines\" its privileged status, ąnd encourage CarbonVotes and other polls to vote on it, which if successful wouuld make clear to the community that this contract is \"part of the protocol\" and so the community *is* responsible for providing ongoing protocol improvements that eventually unlock any ETH sent into this contract]\r\n\r\n### Chain initialization\r\n\r\nWhen a `ChainStart` log is published, this initializes the chain, setting the following parameters:\r\n\r\n* `POW_CHAIN_HASH_ROOT` (new parameter) = `hash_chain_tip`\r\n* `GENESIS_TIME` = `time`\r\n* `PROCESSED_HASH_ROOT` (new parameter) = `hash_chain_tip`\r\n\r\nIt runs `on_startup` with `initial_validator_entries` equal to the list of data records published as HashChainValue logs so far, in the order in which they were published (oldest to newest).\r\n\r\n### Chain updating\r\n\r\nDefine a validator's \"view\" as being the value obtained by calling `DEPOSIT_CONTRACT_ADDRESS.get_hash_chain_tip()` from the post-state of the block 512 blocks behind the current head of the PoW chain. Define a \"valid view\" (defined subjectively from the PoW of a validator) as a value which is a descendant of `POW_CHAIN_HASH_ROOT` and cannot be obtained by calling `DEPOSIT_CONTRACT_ADDRESS.get_hash_chain_tip()` from the post-state of a block that is part of the canonical PoW chain _at least_ 512 blocks behind the head. Note that any valid view should be either equal to or an ancestor of the validator's view.\r\n\r\nBlocks will have a new data field, `hash_chain_tip_vote: hash32`, which proposers are expected to fill with the following algorithm:\r\n\r\n* Let slot B be the last slot during which the `POW_CHAIN_HASH_ROOT` changed.\r\n* If all blocks since slot B contained a `hash_chain_tip_vote` that was either equal to the `POW_CHAIN_HASH_ROOT` or was an invalid view, vote the validator's view.\r\n* If there was at least one valid view published as a `hash_chain_tip_vote` since slot B, copy the first valid view.\r\n\r\nNote that assuming >= 50% honest, this algorithm will converge to all honest proposers voting the same value, which is a descendant of the `POW_CHAIN_HASH_ROOT`. If the same value is voted for in >= 683 of the last 1024 blocks, set the `POW_CHAIN_HASH_ROOT` to this value.\r\n\r\n**Note that this is a vote, not a consensus rule**; blocks with incorrect votes should not be rejected.\r\n\r\n### Deposit processing\r\n\r\nAdd a new type of `SpecialObject`, which consists of the entire hash-linked-list of HashChainValue logs since the previous `PROCESSED_HASH_ROOT` up to the `POW_CHAIN_HASH_ROOT`. If a valid such hash-linked-list is submitted, then we run `add_validator` with the given values for each record, and set `PROCESSED_HASH_ROOT = POW_CHAIN_HASH_ROOT`.\r\n\r\nThis does mean that deposit processing is not \"automatic\", in that deposits are not automatically read from the PoW chain; only a hash is automatically read, and the rest of the data must be manually imported by some block proposer. This is by design, to limit the amount of in-consensus communication between the PoW chain and the beacon chain required to a single hash value."}}
{"actor":{"display_login":"vbuterin"}}