DEPRECATED IN FAVOR OF NEW REPO

This was mostly just an experiment, and parts of this implementation are very bugged. The new repository continues this project, but structured, adhering to Go-lang style, testing, and lots of bug-fixes.

New repository here: protolambda/go-beacon-transition

Code golfed Beacon-state transition implementation by @protolambda.

Submission for Twitter-bounty by Justin Drake: Twitter link Archived tweet

@drakefjustin:

The phase 0 spec (even not fully polished) is slick!

10 ETH bounty to the first person to write in Go (MIT license) the full state transition function (BeaconState, BeaconBlock) -> (BeaconState, Error) in 1,024 lines or less.

27 Feb. 7pm: Challenge accepted. (*insert challenge_accepted.jpeg*)

3 Mar.: Done 🎉

• ~8h of spec python->go porting & interpretation of non-code parts
• ~8h of discussion in chats and GH issues; cutting edges for line limit + going through spec requirements.

The result: a monstrously looking (blame codegolf requirement) but complete spec implementation, in formatted Go.

Even with an absurd line limit, the spec can be implemented.

Now let's get back to work writing (and implementing) an awesome spec. One that is more readable, modular, testable, and useful to the community

Thanks to all ETH 2.0 researchers and implementers for designing such a powerful but minimal specification.

The original intention was to create a transition that is:

• written in Go
  • types
  • low-level code benefits for speed
  • more real-world use-case
  • formal-ish & readable -> easier to verify behavior
• executable (alike to previous Python work)
  • good for testing
  • catch inconsistencies easily with IDE
• fast enough for new experiments
  • fuzzing
  • benchmark different possible extensions/modifications to the spec
• minimal
  • making changes to the spec should be easy
    • no dependencies, externals, etc.
    • clear definitions
  • a spec should not be too big in any case

Some of these intentions had to be ignored to make the line-limit work at the end, hence we are thinking about starting over, without prioritizing code-golfing.

However, the line limit was also good for some things:

• Found several parts in the spec with small inconsistencies / poor wording
• Submitted a PR to fix some things, more to come.
• Scrutinized the necessity of helper functions. Some of the bigger reductions in line count may actually be welcome in the spec.
• Worked out the non-pseudocode parts of the spec. Some parts of the spec look simple, but actually require lots of data joins and lookups, which we want to avoid. Some PRs may follow out of this to make the spec more implementers friendly.

Further project ideas/goals will be discussed on EthCC, suggestions welcome!

proto beacon-challenge (master)$ bash linecount.bash 
file                                    brackets       comments       blanks         not-counting   counting       full           
./challenge/constants.go                0              14             12             26             39             65             
./challenge/containers.go               28             85             32             145            149            294            
./challenge/crypto_util.go              8              5              5              18             25             43             
./challenge/data_types.go               19             11             13             43             58             101            
./challenge/math_util.go                9              1              5              15             22             37             
./challenge/shuffling.go                9              35             5              49             36             85             
./challenge/ssz_util.go                 24             47             10             81             104            185            
./challenge/transition.go               250            201            115            566            598            1164           
total counting lines: 1031
concatenate the files, and you get 1024 (reduce package name lines for 7/8 files) (or less, if you reduce duplicate imports)

Git ref of beacon spec used for this challenge: 8df7de150e68408b78d6488a6f4c9cf8e18c4405 (dev branch around time of the challenge).

bash linecount.bash

Yes this is bad. But fun, and code golfing = more scrutiny towards spec, we look more at the necessity of functions. I.e. the spec improves in the process.

MIT. Container types are adapted from CC0-licensed types in original ETH 2.0 specification doc.