26 Commits

Author SHA1 Message Date
Danny Ryan
de03ebb143
many custody game formatting cleanups 2020-05-19 09:58:33 -06:00
Danny Ryan
3f0e58a8ed
add chunk challenge and response to block and operations 2020-05-19 07:50:05 -06:00
Danny Ryan
3851a26a0f
add phase 1 custody objects to custody-game.md 2020-05-19 07:34:06 -06:00
Dankrad Feist
964bf42335
Fix type 2020-05-01 00:32:02 +01:00
Dankrad Feist
d30f11a781
Fix lint 2020-05-01 00:16:00 +01:00
Dankrad Feist
d58d7627b7
Fix toc 2020-04-30 19:25:18 +01:00
Dankrad Feist
0e2931b9b3
All tests passed 2020-04-28 01:09:20 +01:00
Dankrad Feist
2449db1bb6
Phase 1 block tests are working 2020-04-27 16:08:49 +01:00
Dankrad Feist
ab2ee0e2c2
Restoring chunk challenges and testing 2020-04-24 17:06:27 +01:00
Dankrad Feist
907c56dabd
Fix ToC 2020-04-05 15:47:59 +01:00
Dankrad Feist
c3c24b4fc4
Fix lint 2020-04-05 15:35:11 +01:00
Dankrad Feist
bf34fdf023
Fix ToC 2020-04-05 15:10:09 +01:00
Dankrad Feist
ca6af0c2e9
256-bit custody atoms for better alignment with rest of the spec and greater efficiency 2020-04-05 14:39:00 +01:00
Danny Ryan
073f78efa1
Merge branch 'dev' into phase1-tests 2020-03-29 17:04:25 -06:00
Danny Ryan
d299b06a1c
fix custody bit calculation format 2020-03-16 09:52:27 -06:00
Dankrad Feist
9b7e0ab2be
Fix error in custody bit computation 2020-03-13 17:15:25 +00:00
Danny Ryan
1293320675
Merge branch 'dev' into phase1-tests 2020-03-12 07:12:41 -06:00
Hsiao-Wei Wang
b4c7481b35
Fix the misc table 2020-03-03 01:28:58 +01:00
Danny Ryan
129aa02cb3
support tests with SLOTS_PER_EPOCH * 256 vals 2020-02-10 17:56:05 -07:00
vbuterin
2a91b43eaf
Remove shard block chunking
Only store a 32 byte root for every shard block

Rationale: originally, I added shard block chunking (store 4 chunks for every shard block instead of one root) to facilitate construction of data availability roots. However, it turns out that there is an easier technique. Set the width of the data availability rectangle's rows to be 1/4 the max size of a shard block, so each block would fill multiple rows. Then, non-full blocks will generally create lots of zero rows. For example if the block bodies are `31415926535` and `897932` with a max size of 24 bytes, the rows might look like this:

```
31415926
53500000
00000000
89793200
00000000
00000000
```
Zero rows would extend rightward to complete zero rows, and when extending downward we can count the number of zero rows, and reduce the number of extra rows that we make, so we only make a new row for every nonzero row in the original data. This way we get only a close-to-optimal ~4-5x blowup in the data even if the data has zero rows in the middle.
2020-01-28 17:31:51 -07:00
protolambda
f04a686db7
doctoc 2020-01-14 01:42:19 +01:00
protolambda
702b253361
update configs for phase1 2020-01-13 19:50:36 +01:00
protolambda
419b6a3250
config change, need more space for worst-case reveals 2020-01-13 19:00:24 +01:00
protolambda
507a9afbfb
apply custody bit fix suggestion from Dankrad 2020-01-13 18:57:56 +01:00
protolambda
4732c7beb1
merge in dev (v0.10) and fix reorg/lint issues 2020-01-13 18:55:21 +01:00
Danny Ryan
676e216beb
reorg specs by fork and move ssz out to own folder. make all of the build and link changes to support move 2020-01-10 11:55:13 -07:00