Special thanks to Alex Skidanov and Rongjian (RJ) Lan
For reference, here is the Harmony whitepaper and Github.
We hang out here on Discord and this is our Twitter — come chat!
Topic Overview
Beacon chain [2:56]
- generates secure randomness
- stores cross-link hashes from the other shards
Attacks on a single shard [7:52]
Cross-shard transactions [20:22]
Consensus [24:25]
Randomness [45:04]
Networking [56:56]
Non-technical [1:01:42]
- Mainnet around June/July 2019
- Testnet around two months from mid February
Questions (paraphrased)
1. a) How many shards will there be when the network launches?
~10 to start (under 100). [2:32]
b) What is the max number of shards supported?
The network should support 1000 or 2000 shards, depending on beacon chain’s processing power to verify shard headers and BLS signatures at 500kb or 1mb per block. [5:11]
2. a) Does the beacon chain produce blocks as frequently as the shard chains?
Yes, because it’s running the exact same consensus.
b) Can you send transactions to the beacon chain?
Yes.
3. Why do you need to cross-link? How does it help? [6:37]
The cross-links on the beacon chain help ensure there is only one canonical chain for a shard. This is to prevent the rare case of a shard being attacked with forking.
4. a) What is the max percentage of malicious actors in the global pool? [7:55]
25% [explanation & calculation at 8:50]
b) Why do we need to cross-link? [13:08]
(Context: given the assumptions/parameters, it seems like the probability of having 33% malicious actors is next to zero. It seems like forking is impossible.)
Over time, a single shard can be overtaken or corrupted adaptively after the sharding happens.
c) Can someone can adaptively corrupt more than two thirds?
Yes, with our resharding mechanism, we periodically shuffle the voting power of validators in each shard, and frequently enough to have a low probability of a single shard being corrupted. [14:18]
6. How do you prevent 2/3 of a shard being corrupted and creating a fork? [15:22]
We will make sure that this will never happen with a high enough frequency of resharding. [17:00]
7. How is the beacon chain made more secure than the shard chains? [18:30]
The beacon chain will be assigned more staking eg. two times more.
8. How often are blocks produced?
Every few seconds via BFT consensus optimized to scale linearly.
9. How does Alice send money to Bob if Bob is on more than one shard? [20:22]
Create a transaction specifying the source address and destination address. The source shard will debit your balance, generate a proof (eg. a receipt) and send it to the destination shard. This shard will verify that the proof is valid and credit the destination address.
10. a) How do smart contracts express cross-shard invocations? [22:00]
Most of the work is done by a single shard, whereas for cross-shard smart contracts, we are only supporting the ‘read’ operation, and not the update.
b) How does reading work? [23:00]
It’s more like pubsub mechanism. If your smart contract will be reading fields in your other smart contract, you would specify that. Validators in the other shard will publish the field data of interest whenever the data changes. Your shard will listen to that, and execution of your smart contract won’t be blocked.
11. a) How is the reward distributed? [27:56]
Equally, including those that did not participate.
b) What is the motivation to participate? Why even be online once I’m assigned? [28:04]
For those too slow to sign, it can be okay, but we’ll drain the voting power of those that continuously fail to sign. [29:30]
c) Does the leader rotate? [29:58]
At first we’ll keep it stable if the leader performs honestly.
d) So if the leader wants to punish a validator, could they not include their signature?
A filtered validator broadcasts proof that they signed (though the other validators don’t rebroadcast the message).
e) How is a leader re-elected and when does that happen? [31:42]
We’ll have a timeout counter based on the normal consensus speed. If the leader doesn’t reach consensus by timeout, everyone is free to initiate the leader change protocol, which will be the same as the traditional PBFT algorithm.
f) How is this timeout chosen? What is the process? [42:00]
It’s based on the previous performance, adjusted according to the history and network conditions.
g) Why do we need any BFT consensus when we have the cross-link? It would be more efficient. [38:02]
The BFT consensus is the main security safeguard, while the cross-link is another layer of security guarantee. The BFT consensus is a must-have and the cross-link is good to have, in terms of security.
12. If you’re committed to using a partial synchronous algorithm, why not use Tendermint, which does not have a view change? [39:20]
13. What if the leader just produces empty blocks? [40:18]
14. Isn’t it a problem that the leader has the sole power to include or exclude transactions? Censoring transactions with the excuse that the block is full. [41:12]
15. Harmony uses a gossip network. [44:15]
Randomness [45:04]
At the start of the epoch, the leader announce to other validators using the previous block hash. Every validator uses the VRF to sign this message back to the leader. Leader waits for F+1 VRF results and aggregates this into a pre-image of the randomness (pRnd) and then run the same PBFT consensus so that it gets committed to the next block. The pre-image is input into the VDF to generate the true randomness (Rnd). The VDF is configured so it’s more than one block time eg. 10. Then you run consensus again and then commit Rnd to block.
1. a) Which VDF will you use? [48:26]
Likely the Ethereum one.
b) Ethereum’s VDF will use an ASIC — do you expect the leader to use this ASIC?
No, we can adjust the VDF time to make it longer if the leader doesn’t have the ASIC.
2. Will smart contracts have access to the randomness? [51:17]
We haven’t decided that yet, because there isn’t a defined period for randomness, so you may not have randomness for that block. It’s a question we’re still researching.
3. Theoretical beacon fork situation discussion [52:00]
4. The security assumption is that the beacon chain will never fork [54:50]
5. Alex argues that either 1) forks are possible or 2) you don’t need cross-links [55:15]
We’ll guarantee with high probability that the beacon chain won’t have forks by using more staking. We haven’t decided, but before the mainnet, we’ll have a clear analysis of how much the stake should be.
Networking [56:56]
We’re optimizing the technology at the networking layer. Let’s assume the sender is broadcasting block of size ‘m’. If we have ‘d’ neighbours, then we have m*d network load on the sender. When the block is large (eg. 1mb), it will be a bottleneck for the sender.
We’re using erasure coding to encode the block with extra erasure code, and then cut it into chunks and equally send to ‘d’ neighbours. So each neighbour only has a part of the encoded block, incurring a significantly reduced load compared with the sender.
1. How do they recover the (partitioned) block? [59:05]
Nodes communicate among themselves to re-encode the chunks into the block, even if 1/3 of the blocks are malicious and not participating.
2. Why are you using fountain codes? [1:00:12]
Erasure coding is traditionally based on Reed Solomon encoding, which is a fixed parameter. Instead, we’re using RaptorQ fountain code, which is continuous and adaptive eg. at first you can have 30% and then generate additional pieces, bit by bit, which can be part of the reconstruction. This increases the probability of the receiver receiving the whole block.
Non-technical [1:01:42]
1. When is the mainnet launch? Around June/July 2019.
2. Testnet? Around two months from mid February.
Hopefully you found this useful. Feedback is welcome.
🐦 I’m on Twitter: https://twitter.com/Ether_Gavin
