,
15 tweets,
3 min read
Read on Twitter
1/ I just did a deep dive into the new Nightshade paper from the @NEARProtocol team which @scalarcapital backed. Summary of the highlights below.👇 nearprotocol.com/downloads/Nigh…
2/ The plan is to replace shard chains to shard chunks. System is modeled as a single blockchain, rather than a nested blockchain. In each block, a shard may or may not be represented via a chunk.
3/ Nightshade uses heaviest chain consensus rather than BFT. They also plan to use a finality gadget, currently planning to use Casper CBC (correct-by-construction), but may use their own proprietary research called TxFlow.
4/ Nightshade has two roles: block producers and validators. Initial plan is to have 100 producers and 10,000 validators. No guarantee that they are distinct entities, however each needs to put up a separate stake deposit. The top 100 stakeholders are the block producers.
5/ Data availability in Nightshade is solved in a similar fashion as Polkadot. Data is divided into slices with redundant information added, so that the original data can be restored with just a subset of the slices (erasure encoding).
6/ A shard’s chunk is not included unless the block producer verifies that they received their erasure encoded slice of the chunk, called a onepart.
7/ What about validators who wish to sign regardless of whether they actually received and verified their oneparts? Nightshade ensures honesty by requiring block producers verify properties of their specific onepart. Dishonesty here is a slashable behavior.
8/ To ensure speedy cross chain transactions, Nightshade requires cross shard transactions receipts be included in the onepart messages and be processed on a first come first served basis.
9/ Nightshade allows anyone to challenge invalid blocks. Furthermore it imposes a limit on the amount of state each transaction can input or output to ensure that challenges can be compact.
10/ Nightshade chooses not to wait for the challenge period to apply cross shard transaction receipts. Instead, they roll back subsequent blocks if an (likely rare) invalid block is found. This results in faster transactions, but risks them being considered non-final later.
11/ To hide validator identities in an effort to thwart adaptive adversaries, Nightshade uses a verifiable random function (VRF) to assign validators. It also asks that they sign on blocks and not chunks to conceal which shard they are actually assigned to.
12/ Nightshade avoids lazy validators by using a commit-reveal scheme to prevent validators from copying each others’ work.
13/ Aggregating validator signatures on chain would become quite expensive, so instead block producers aggregate them locally and then attest to this aggregation with their own signature. The fact that the producer is not challenged and slashed is relied on for validity.
14/ To avoid block producers censoring validators, Nightshade has two answers. 1) Economic incentives (block producers are paid based on the number of validators assigned to them). 2) Allowing validators to remain loyal to a particular block producer of their choice.
15/ Nightshade plans to use Schnorr multi-signatures to allow all block producers to attest to a particular block, called snapshot blocks. Schnorr signatures are easily validated on other chains, and may allow secure cross chain transactions in the future.
