Why should I trust NNS Ledger, seriously?

Developers
,
1

Just saw a new project announced on twitter:

Which made me thinking, how can I trust transactions on the NNS Ledger?

One may argue that its code is open source, and there is nothing malicious in it. But hypothetically, if tomorrow someone were to accuse DFINITY Foundation by saying a million ICP was moved from his account to another one without consent, what can the foundation do to prove there is no foul play?

I understand that NNS Ledger keeps all historical transactions permanently in archive canisters, but these records only show which account is debited and which account is credited, and there is no record of authorization, whether a user signature or a canister’s (which is even harder since canisters don’t sign a signature to transfer ICPs).

What evidence can show that it was not the Foundation who manufactured a transaction through a malicious upgrade (followed by another correct one that covers the trail)?

Now that question gets into how NNS works, since all upgrades are handled by NNS. But by the same logic, why should I trust the records kept by NNS? NNS may also self-upgrade to remove malicious records from its state.

It seems to me that the only proof is the raw block data since genesis. Do node providers keep those?

I hope everyone can see why this is a HARD problem. Now imagine every DeFi project would have to answer similar questions… Did nobody realize this was a problem? Hard to believe…

Anyway, LaunchTrail seems to be “right on money”, solving the real problem so (hopefully) end users can go back to DONT TRUST, VERIFY!

6 Likes
2

I think this raises the broader question of how end users can verify that a so-called decentralized application is really decentralized, i.e. cannot be changed unilaterally by any one party.

Or let’s say a dapp (or the NNS in this case) can be changed through some vote.

I think it’s worthwhile to always publish a complete and immutable history that describes something that is mutable. That way, end users can always fall back to checking that history. (The issue is that it will grow unbounded…)

As you said, I think it makes sense to add a record of authorization to the ledger canister.

But yeah, more generally, perhaps you really do have to rely on “experts” and auditors to ensure that a system is decentralized like they claim…

5 Likes
3

I’m also very concerned about this. I recently upgraded the fungible token standard to v0.5.0, incorporating ledger’s blockchain design, but a new question came up: how does ledger prove that the data written to the blockchain is trustworthy?

2 Likes
4

Would be good to hear someone from the foundation on what they think of this topic. I’m sure BTC holders will be eager to know whether their assets will be safe in the smart contracts hosted on IC @dieter.sommer @diegop

2 Likes
5

@quinto the NNS is run on a subnet itself ran by multiple node providers, the biggest majority of which are not the foundation (see here).

Assuming then that the majority of node providers are honest, it then comes to the NNS itself.
The code that the NNS runs is public and it can be easily verified that each NNS canister upgrade uses the public code that it says it uses (see this proposal’s summary for an example).

Note that the dashboard (maintained by the ICA, not dfinity) is not even the only place where proposals can be viewer, there are others and ultimately any user can do it, so even if a malicious proposal would disappear from the dashboard, it couldn’t be deleted from the internet.

There would then be a record of a malicious change (or changes) in the form a proposal trail.

2 Likes
6

An attacker could upgrade to malicious code that erases the very record of this upgrade. So it depends on whether this attack can be caught in the act by the public?

1 Like
7

@quinto well yes, but anyone can build a tool that polls the NNS and stores all submitted proposals, since the record is public.

To delete/replace a transaction in the ledger you’d have to do at least three upgrades (ledger, archive and governance) all malicious and then hope that nobody saw any of those proposals being submitted, which seems very very unlikely and any user can build a tool to make sure it’s impossible by polling the NNS (I’m sure there are some out there already besides the dashboard, ic.rocks used to be one, though it seems down atm).

1 Like
8

Thank you for for the answer. But “very very unlikely” is not the same thing as verifiability.

It seems to me that the actual block data is the ultimate source of truth. I understand IC consensus doesn’t need the full chain since genesis in order to function, but do node providers keep those for verifiability purpose?

1 Like
9

@quinto I only said very very unlikely because I can’t find (right now) another thirdparty tool (besides the dashboard, which you’d also have to upgrade) that polls the NNS for proposals. Almost certainly there are such tools already running and ultimately you can’t be sure there aren’t any, so the prospects of doing this under the radar are analogous as posting a password to facebook and removing it a few seconds later and relying on no one having seen it.

10

There are backups of the blocks (which are certified by the network and thus verifiable) and there is a plan to make those public, but there are a couple of things that need to be done first, like move II to another subnet (publishing the blocks and state of II would not compromise security, but would compromise privacy).

1 Like
11

Trustless is myth. There is always some trust involved at deeper levels with any decentralized technology

  1. In Bitcoin you are trusting that majority of nodes don’t collude. Same with ethereum proof of work

With proof of stake, you are trusting a few entities who stand to looses a LOOSE a lot( exponentially) more if they act maliciously. The Ledger upgrades are gated on collective votes of the neuron holders. There is NO incentive/reason for neuron holders to vote yes on malicious proposal that would put any icp (and thus their neurons) and it’s value at risks

So there is always some trust and involved. You just have to know and understand what/whom are you trusting.

Also, Immutable contracts is not the answer here. software bugs are a reality that every project has to deal with. IC is well covered on this front by solid engineering, audits, reviews and backups

So absolutely you can trust the NNS to do the right thing. This is 99% of the IC’s charter

What is 100% guaranteed is auditable trail of upgrades, transfers etc. ie if something fishy happens ANYONE be able to flag it. We should discuss more on the “auditable” properties of the ledger

2 Likes
12

So when these tools are keeping records, are the records verifiable? Is the completeness of these records verifiable?

1 Like
13

Yes I do agree. But with bitcion or ehthereum, at least there is “proof” of something wrong happened. Attackers won’t be able to cover their trails.

1 Like
14

All operations on the IC and the IC ledger are auditable. No one can cover their tracks after pulling of a action that is outside the specification of the IC. (Either maliciously or due to bugs)

Auditability will be right direction to steer this discussion. The IC is 100% auditable - even the wasm binary code that gets generated can be audited to match the source code.

Can you please share Which part is not auditable ? Ie how can a malicious actor cover his/her trails

1 Like
15

A I mentioned in the text, ledger could upgrade itself to change its own state. Not auditable unless the upgrade is auditable.

Then the upgrade is managed by NNS, but NNS could also self-upgrade to change its own records. Not auditable unless all the blocks in the block chain is made public.

Note that merely showing something recorded by a 3rd party tool is not “auditable” either, unless there is hard cryptographic proof show these records are complete and not forged.

Note also that this question has nothing to do with node providers being dishonest or network being centralized or not. To launch the attack one only has to take control over NNS upgrades, either through exploits in code, or social engineering, or anything.

My point is that unless you can show the hard proof (under reasonable assumptions, such as not all private keys of nodes are compromised) of the upgrade records are complete and verifiable, they cannot be trusted.

1 Like
16

Agree with your last point - ALL information needed to cryptographically verify final state should be publicly accessible. I “believe” this information is available or at least we have a process in place for the community to ask for such info/feature via proposals. Please identify the exact information that’s missing and submit a proposal :slight_smile:

coming back to audits

Any Malicious change to NNS code has to through

  1. nns votes. which are “impossible” to forge

Or
2. Compromise of enough key material to update arbitrary code, which is — “impossible”. With chain key technology that autonomously rotates key periodically any key compromise scenario is super hard to pull off.

Or
3. Bugs: there is enough machinery in place to detect and stop deployment of bad code. Multiple control points and safeguards will have to fail simultaneous for a bug escape to land on the Root subnet. Again it’s a “process” which is constantly improving.

1 Like
17

Well, I agree with you on these points that an attack is hard to pull off. We developers building on IC are betting on the platform because we have a good degree of trust in the team behind it.

But that does not shun away from the question. If I were to ask today, can the foundation (or better yet, a node provider that is not the foundation) provide cryptographic proof that the state we see on chain (e.g. the list of proposals we get from querying nns canister) is the truthful state that has evolved from genesis? For btc or eth, I bet no one would hesitate to say “YES”.

Since @dralves mentioned above there is plan to make block data of the NNS subnet public, so I can take that as a soft confirmation that there will be more transparency in the future. But the question still stands for everything happened in the past. Will all block data of NNS subnet since genesis be made public?

1 Like
18

@quinto

Please submit a proposal, this is a valid ask . I would not take any forum discussion as a roadmap commitment (soft/hard).

If this is important enough for the larger community a proposal is the right way to go forward.

In the proposal please add

  1. What information is missing ?
  2. How would the information help the general community as a whole
  3. The IC state is growing 5x the speed of 2nd largest chain. Keeping historic state perpetually would incur cost so do include any ideas that you have about how this project would sustain itself.

Submitting a proposal is straight forward, let’s us know if you need any help on that.

Cheers
-F

19

Anyway, LaunchTrail seems to be “right on money”, solving the real problem so (hopefully) end users can go back to DONT TRUST, VERIFY!

I just spent some time reading the LaunchTrail README. I think it unlocks a bunch of interesting use cases around canister verifiability and transparency, without having to necessarily go the 100% decentralized route of making your canister open source and non-upgradable. Thanks for sharing!

1 Like
20

This tool looks great!