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.
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?
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
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.
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.
“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.