Title: Theory / Unimportant / Compagnie considérée / Near / Sharding
On every note of this deck, unless a note says otherwise:
Page: https://near.org/papers/nightshade/#glossary

Name: A shard
Definition: One blockchain out of a set of related blockchains
Page: https://near.org/papers/nightshade/#sharding-basics
Context: Near

Name: The beacon chain
Definition: A block chain in charge of orchestrating the various shards.
Page: https://near.org/papers/nightshade/#sharding-basics
Context: Near

Name: sharding
Definition: Approach, in which the work is split among all the participating nodes.
Page: https://near.org/papers/nightshade/#sharding-basics
Context: Near

Name: Synchronous cross-shard transactions
Definition: Whenever a cross-shard transaction needs to be executed, the blocks in multiple shards that contain state transition related to the transaction get all produced at the same time, and the validators of multiple shards collaborate on executing such transactions
Page: https://near.org/papers/nightshade/#glossary
Context: Near

Name: Asynchronous cross-shard transactions
Definition: A cross-shard transaction that affects multiple shards is executed in those shards asynchronously, the “Credit” shard executing its half once it has sufficient evidence that the “Debit” shard has executed its portion.
Page: https://near.org/papers/nightshade/#glossary
Context: Near

Question: When there are multiple blockchain communicating, what is the standard way to synchronize them and ensure they are sure that a block from the other chain is valid
Answer: Using a beacon chain that regularly state which is the official chain up to know
Context: Near

Question: Why even if you check the entire shard on which you are making a transaction you can't be sure the transaction is entirely valid
Answer: Because it may relies on an interaction with another shard, based on an invalid transaction.
Context: Near

Name: Chainweb (Kadena. Maybe there are other names)
Definition: A sharded blockchain with a graph relating shards. A block processor of shard S can only produce block for S, should validate all neighbours shards, and can only accept transaction with neighbors shard
Page: https://near.org/papers/nightshade/#glossary
Context: Near
Intuition: A transaction between two shards should find a path in the graph; ensuring that two shards must be corrupted for an invalid transaction to be accepted

Question: Why does Chainweb still allow for relatively easy corruption
Answer: Let's assume that Shards S1 and S2 are corrupted. Generate an invalid block in S1 and validate it in S2. All neighbors of S2 will see it is a valid shard, so will accept transaction from S1 passing through S2
Context: Near

Name: Fisherman
Definition: Allowing, for some time, a honest validator in a shard S, to send a proof to shards using S that they used an invalid block.
Page: https://near.org/papers/nightshade/#glossary
Context: Near

Question: What are the downside of fisherman
Answer: Period needs to be long enough to detect and send proof of invalidity. However, the longer it is, the greatest delay it adds to transaction
Context: Near
Answer2: This lead to attacker spamming with false invalidity proof

Name: Grieving attack
Definition: An attack consisting in spamming warning that some block is inavlid wile actually it is not
Page: https://near.org/papers/nightshade/#glossary
Context: Near

Name: A notary
Definition: Someone whose role is to assert they have been to download a block, and potentially prove it
Page: https://near.org/papers/nightshade/#glossary
Context: Near
Etymology: Avoiding the risk that a corrupted actor sends a block that was not actually on a chain

Question: What is the problem with notary
Answer: They can not prove that they have downloaded a block. So easier to do it dishonestly
Context: Near

Question: What is the advantage with notary
Answer: It requires to downoad a single node, so a notary can be quickly rotated between shards
Context: Near