{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/2","repository_url":"https://api.github.com/repos/ethereum/eth2.0-specs","labels_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/2/comments","events_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/2/events","html_url":"https://github.com/ethereum/eth2.0-specs/issues/2","id":362831452,"node_id":"MDU6SXNzdWUzNjI4MzE0NTI=","number":2,"title":"TODO: SimpleSerialize (SSZ) spec","user":{"login":"hwwhww","id":9263930,"node_id":"MDQ6VXNlcjkyNjM5MzA=","avatar_url":"https://avatars3.githubusercontent.com/u/9263930?v=4","gravatar_id":"","url":"https://api.github.com/users/hwwhww","html_url":"https://github.com/hwwhww","followers_url":"https://api.github.com/users/hwwhww/followers","following_url":"https://api.github.com/users/hwwhww/following{/other_user}","gists_url":"https://api.github.com/users/hwwhww/gists{/gist_id}","starred_url":"https://api.github.com/users/hwwhww/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hwwhww/subscriptions","organizations_url":"https://api.github.com/users/hwwhww/orgs","repos_url":"https://api.github.com/users/hwwhww/repos","events_url":"https://api.github.com/users/hwwhww/events{/privacy}","received_events_url":"https://api.github.com/users/hwwhww/received_events","type":"User","site_admin":false},"labels":[{"id":1063043869,"node_id":"MDU6TGFiZWwxMDYzMDQzODY5","url":"https://api.github.com/repos/ethereum/eth2.0-specs/labels/help%20wanted","name":"help wanted","color":"F0C808","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-09-22T06:33:19Z","updated_at":"2018-10-05T15:36:06Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Open an issue for following up our discussion on gitter.\r\n\r\n## Specification requirements\r\n- Design rationale\r\n    - Directly mapping to the specified type and speeding block processing up. (by Vitalik from https://www.youtube.com/watch?reload=9&v=cp0LxJiyV3I)\r\n- Encoding\r\n- Decoding\r\n- Types\r\n   - Integers\r\n       - [not in the current implemenation] Specify the signed and unsigned integers support.\r\n       - [not in the current implemenation] Static types?\r\n\r\nAnything else? :)\r\n\r\n## Reference\r\n- [Python implementation - Vitalik's latest implementation in beacon_chain repo](https://github.com/ethereum/beacon_chain/tree/master/ssz)\r\n- [Rust implemenation - Lighthouse SSZ](https://github.com/sigp/lighthouse/tree/master/ssz)\r\n- [Lighthouse Serialization Sandbox Output](https://notes.ethereum.org/s/BkM5bqsIQ)\r\n- [Ethereum Yellow Paper - Appendix B: Recursive Length Prefix (RLP)](https://ethereum.github.io/yellowpaper/paper.pdf)\r\n- [The EVM Jello Paper - Recursive Length Prefix (RLP)](https://jellopaper.org/data/#recursive-length-prefix-rlp)\r\n- https://github.com/ethereum/beacon_chain/issues/94: simple_serialise - not possible to parse the structure without type information \r\n- https://github.com/ethereum/beacon_chain/issues/112: ssz intX type is actually uint\r\n\r\ncc @vbuterin @djrtwo @arnetheduck @mratsim @paulhauner @NatoliChris @poseyy\r\n"},"comment":{"url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/comments/427407466","html_url":"https://github.com/ethereum/eth2.0-specs/issues/2#issuecomment-427407466","issue_url":"https://api.github.com/repos/ethereum/eth2.0-specs/issues/2","id":427407466,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNzQwNzQ2Ng==","user":{"login":"arnetheduck","id":1382986,"node_id":"MDQ6VXNlcjEzODI5ODY=","avatar_url":"https://avatars3.githubusercontent.com/u/1382986?v=4","gravatar_id":"","url":"https://api.github.com/users/arnetheduck","html_url":"https://github.com/arnetheduck","followers_url":"https://api.github.com/users/arnetheduck/followers","following_url":"https://api.github.com/users/arnetheduck/following{/other_user}","gists_url":"https://api.github.com/users/arnetheduck/gists{/gist_id}","starred_url":"https://api.github.com/users/arnetheduck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arnetheduck/subscriptions","organizations_url":"https://api.github.com/users/arnetheduck/orgs","repos_url":"https://api.github.com/users/arnetheduck/repos","events_url":"https://api.github.com/users/arnetheduck/events{/privacy}","received_events_url":"https://api.github.com/users/arnetheduck/received_events","type":"User","site_admin":false},"created_at":"2018-10-05T15:36:06Z","updated_at":"2018-10-05T15:36:06Z","author_association":"NONE","body":"Based on my understanding, one of the priorities of the format was efficient in-memory access (along with a willingness to pay a price in terms of space efficiency)\r\n\r\nI just went through the exercise of hardening our implementation against overruns and misaligned pointers (https://github.com/status-im/nim-beacon-chain/pull/7 - hopefully caught all of them :smile:) - the following things are noteworthy, when writing cross-platform code:\r\n\r\n* every field (of size >1) much be alignment-checked, including list items - this causes some performance degradation and prevents us from using `mmap` and the like to directly map the data, when loading from a trusted source\r\n* while it's possible to carefully nurse specific structs to minimize misalignment issues by manually ordering fields in a particular way, it remains impossible to do so generally:\r\n  * anything following a variable-length field can be misaligned\r\n  * anything that has a mix of type lengths will need to manually add padding/dummy fields\r\n\r\nA possible solution to this issue is to introduce a rule to the serializer that ensures that padding is mandatory and deterministic:\r\n* 0-pad any data up to the size-aligned boundary of the next field (4 or 8 bytes for variable-length fields - the size must be aligned, but also the items themselves)\r\n* introduce field-reorder or possibly a check, such fields in the serialized format remain ordered by size, descending - this minimizes the amount of padding necessary, but also makes it harder to do upgrades / add fields\r\n\r\nFor a good example of a well-aligned format, check out https://google.github.io/flatbuffers/flatbuffers_internals.html\r\n\r\nIt is worth to note that modern X86 processors have mostly solved unaligned access and the performance penalty is small - nonetheless, for several cases of optimized access, even X86 requires aligned data as the optimization level of the compiler gets cranked up - sse4.2 for example, as seen here: http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html"}}
{"actor":{"display_login":"arnetheduck"}}