You claim that you don’t need to download the whole chain to verify with your keychain tech. Basically then you can’t verify that all state transitions happend correctly. Why is that not a problem?
Because you can verify each state change (without knowing the full history) due to chain key cryptography, so you don’t need to verify the previous changes. The innovation is in the single public key of IC that can be used to validate transactions and distributed private key (as I understand, a single key is put together from many nodes - very cool tech) for signatures. Also subnets to optimize this further and not need a global consensus for everything.
1 Like
So: Ethereum 1.0 picks one validator that signs the block while in IC every node signs with its partial key.
Now in Ethereum I need to check if all validators did sign correctly the entire history.
IC just says, yeah look at the current block the nodes still agree that its all fine.
So because I can’t trust a single validator about current state but I can trust the commitee of all validators, because of this, we dont need state history.
Is this correct?
Update: https://epicenter.tv/episodes/406?play=true
00:55m It’s indeed that you trust the other nodes having correct states. IC simply does not check if the states have been manipulated. Only that the current state is signed by the BLS treshold key
Final conclusions:
-
Ethereum 1.0 needs to verify the entire chain for a node due to the election of one single verifier. The other nodes must validate the verifiers decision against their own knowledge and if needed reject the block proposed.
-
IC knows that the majority signed the state already, therefore it can accept it.
-
This means that Ethereum still has more reliability on the consistency of all state transitions, but: the benefit of full verification diminished with key chain tech to that point that Dfinity decided not to make historical state verification a feature therefore eliminating state bloat. This is an important decision, IC is a distributed system, maybe a distributed ledger, but not a blockchain: there is no chain of blocks.
Consequences:
-
An attacker could change the state inconsistently with history by replacing the nodes. I don’t have knowledge how NNS and other stuff is preventing it.
-
The IC benefits a lot from dropping history: no state growth, fast finality, fast sync.
2 Likes
“replacing the nodes”, from your understanding of Chain Key technology is it that anything else other than NNS can introduce new nodes?
Probably not. Also: NNS Governance itself is complex enough FOR ME to not be certain that it is secure enough.
One should note that the lack of complete state history does not preclude you from keeping your state history for your own app. In fact the ledger for ICP does this.
Sir, may I ask what you specifically meant by this? I’m trying to wrap my head around this. So in ethereum’s case the state root of a shard is put into the beacon chain, which is maintained by all of the validators in the network as far as I understand. That would mean the an attacker could not rewrite history as the roots would change, is that correct?
In ICP’s case there is not global state, so no roots are put onto a “global” chain. So if one subnet becomes malicious it could rewrite the state of that subnet. Is that correct?
So you are saying one could keep track of one specific canisters state sort of as a backup? I don’t understand what you mean by “In fact the ledger for ICP does this.”
Thank you for any help.
I think that if one malicious subnet rewrote its state that it would not be accepted by the other subnets and thrown out of the consensus mechanism.
Each canister is its own smart contract. That smart contract can its own merkle tree/chain schema to keep track of state changes. It can keep a log and users can verify that nothing has changed over time. That canister will be much harder for even a malicious sub net to change state because they would have to recalculate every state change ever. It is like putting ethereum in a canister. So you end up with a bunch of ethereums that can all trust each outer because of the consensus mechanism.
1 Like
Yes, I’d say that is correct: the state of a subnet is observed by others, including other subnets, using various protocols that all rely on the subnet’s threshold signature. Whoever controls that key (e.g. a majority of the nodes) and is in a position to take part in these protocols (nodes, or the network) can change the subnet state arbitrarily.
1 Like
My understanding is that the IC chooses a trade-off here. You simply cannot independently verify all state changes of all subnets. Instead, you rely on the BFT guarantees of each subnet to produce a correct result.
I would say this is something that Ethereum and similar chains have that is in its own right strictly better than the IC. The trade-off allows the IC to have massive scalability.
Ethereum may start heading down this road though as well once they implement sharding, as I imagine it will be difficult to run a full node for all shards…though with data-only shards and zk rollups perhaps this won’t be a problem.
A possible solution to this trade-off is the introduction of a zk execution environment for the IC, which could allow verification of state changes with a simple cryptographic proof that is easy to verify. Ethereum and I would assume most other general purpose blockchains would adopt this tech when feasible.
That being said, I think the IC is possibly choosing the better trade-off for the long term, since we get massive scalability now and can hopefully retrofit a zk vm later and thus remove the independent verification trade-off.
1 Like
Thank you, that makes sense.