The node machine SEV-SNP hardware attests that the virtual machine is running the replica/client software inside an “enclave.” There’s no way to make the SEV-SNP hardware do the attestation if that isn’t the case. That’s why it protects the data from anyone with physical access, including node operators (or at least from anyone that can’t break SEV-SNP)
3 Likes
This is just the social proof thing. People get accustomed to one way of doing things, and extrapolate that because everybody is doing it, then that’s the only way that it can be done. But it’s absolutely not necessary for security according to the math and science imo.
They should be much more worried about the fact that on other chains a) they run their user experience on the cloud, or use the cloud, which lays them open to hacks as per BadgerDAO, and being blamed by regulators etc etc, and b) that oftentimes, they maintain a centralized “administrator backdoor” master key, which makes it possible for a team member to go rogue, which problem they could solve with a more sophisticated DAO like the SNS.
It IS true that some DeFi services need to track usage to avoid regulatory heat. The prevailing model does allow that to be done through blockchain explorers, such as Etherscan, without requiring anything extra of the developers. But that kind of history tracking is a terrible experience for real users, and is only suitable for blockchain analysis sleuths.
If a DeFi service wants to make key events and transactions transparent (and this will often be very desirable) a much better way is just to log critical events and transactions inside the DeFi smart contracts, and then provide a nice UI for the log.
Note that something like a DEX will already wish to log transactions, since users will want to see how their trades happened, etc. Imagine having to go to Etherscan to work out how your trades got executed on something like ICDEX. It would be a nightmare.
Final note: DeFi services running on the Internet Computer can also add features that allow people to run service-specific local nodes that track transactions/state changes. That’s what’s done with the governance token ledger, which behaves similarly to a traditional blockchain, and can be accessed via the Rosetta API, so that CeFi exchanges like Coinbase or Binance can interface with them.
The key takeaway is that the Internet Computer blockchain provides a tamperproof and unstoppable scalable compute platform for smart contracts. Such is the power of the platform, it’s possible to build anything desired on top, including logging, and even facilities supporting service-specific “local node” validators that track every change and make sure it is legal
3 Likes
Saving DEFI transactions and logs on chain is contradictory as we want save Disk space. Having logs inside the blockchain state is much more expensive than having them on SSD as logs don’t need to be indexed and hashed in state for root hash. If we could have real blocks instead of Ledger’s fake block with no signatures we could save a lot of blockchain state as well as showing people the real signatures. On one side, IC is removing blocks history for saving Disk but on the other side, IC is encouraging Developers to waste on chain state. To keep in mind, we only got 500 GB memory state per Subnet. And if we are duplicating the logs, which could be done by caching the block instead of caching them in state, we are actually wasting the blockchain state that could be used for more DApp memory
2 Likes
What do you mean when you say “crypto math”?
1 Like
Dominic… you’re telling me to “trust the math” but barring me from seeing what math is being executed. Huh?
It doesn’t matter if you put the math in a whitepaper, the network could be running something completely different. How do I know the network is doing what you say it will if I can’t verify it myself?
Re: local nodes being fed a false state by a malicious subnet, wouldn’t the concern be that the subnet is compromised, rather than a read-only copy being tainted?
I still see no social reason to not add local nodes. Sure, we can argue all day that the math works out and they’re not strictly necessary from a purely technical perspective; but the IC cannot execute on its vision to “replace the internet” if we don’t start winning brownie points with people and sway them to the IC. I’m just trying to help.
2 Likes
Based on this, I would rather rely on the math, and to have the math strengthened, than on an army of validators slaving away to validate ( to validate what could anyway be modified state after an isolation in the absence of math). I would rather have the math and the SEVs strengthen, in order to have a functional but nimble blockchain; and to preserve the security of voting. This is generation III Blockchain anyway, and we can chart a new way forward, and a new normal, and not be bogged down by old thinking.
1 Like
I agree with the saying that what can be done with math, don’t leave it to people.
However, the mathematical community is subject to a rule that results are openly verifiable.
Let us explore some of the most fundamental questions of blockchain.
- Who has the ability to judge right and wrong?
- What is the state of trustless?
- What power do market users need?
From an objective point of view, my opinions are.
- Who has the ability to judge right and wrong?
When a system has an impartial authority, it is easy to leave the decision of right and wrong to it. But such an authority does not exist in the world. And the question of right and wrong is sometimes easy to judge and sometimes hard to judge, even if what most people judge to be right at the time may not really be right later.
The POW system remains completely neutral, leaving the question of right and wrong up to the miners to decide. But to prevent the majority of miners from making the wrong decision, a fork mechanism is retained (this is to preserve more possibilities and ensure that the few deciders can continue to struggle to survive until the market finds out they are right), a bit like “biological evolution”. The POW system does this at the cost of data non-finality.
The POS system, and IC, avoids the chaos of forking and achieves data finality, but also loses the opportunity to “preserve more possibilities” by assuming that the “smart majority” can make the right choice at the time.
I’m not saying which is better, I’m just saying that it’s a trade-off that each blockchain system makes for its own goals. Judging right and wrong is inherently difficult, and blockchain maintainers need to be as neutral as possible and not choose for users when they don’t have to (giving the choice back to them). - What is the state of trustless?
Blockchain systems require a trustless environment, which is the most essential difference from AWS.
IC has Chain-Key technology and SEV hardware, but can these technologies alone solve the trustless problem? No! I’m not doubting the cryptography and hardware, but I’m not endorsing the implicit trust assumption that “we need to trust that the nodes are running the same open source programs and have not made any hack changes to the hardware”. No matter how you prove it, we need to trust an organization, either the Dfinity Foundation or a company like AMD. This is not the trustless environment we want. You know, when a contract is worth tens of billions of dollars, 13 nodes would still love to get together and conspire to do something.
One proven solution for a trustless environment is: open source code + openly verifiable blockchain data. - What power do market users need?
The maintainers of blockchain project have more power over the system from the beginning, which is inevitable in the early stages of ecological development. But one power that the market needs to retain is the power to a publicly verifiable power and the power to choose. (power to choose can be achieved through NNS voting). The verifiable power may not be used by the market in the early days of the ecology, but it is important to reserve this power for the market, and as the ecology matures, it is about who makes the ultimate decisions on the ecology’s development.
Based on the unique properties of IC, open nodes cause data sync difficulties and cost, I also express my views.
- What the market wants first is a verifiable power and the power to choose, and only then is the question of cost considered. This power cannot be given up because of the high cost.
- Data synchronization difficulties and cost issues can be solved by technical solutions. For example (some possible ideas. I am not an expert in this area)
a) The signed block hash tree is stored permanently and is fully public. The amount of data here is small and there is no privacy issue. Then the data of the nearest N blocks of the “public subnet” will be made public and an API will be provided, and the market players will decide whether to download it or not.
b) A disguised approach is to turn the public subnet into a low-storage subnet to reduce the data volume, and a possible solution is to significantly increase the Cycles cost of storage in the public subnet.
c) Create a layer-2 network between edge nodes to do light nodes to quickly verify the data and request the corresponding packets only when the original data is really needed. - I’m not against it: some subnets keep the status quo without disclosing data to meet some of the demand.
If the Dfinity team is not sure if they need an “public subnet”, could they open a few “public subnets” to the market and see how the market grows?
Years of experience in economics have taught me that the more freedom and opportunity you give the market, the more possibilities the market will create.
Regarding the assumption of “trust majority honest” in blockchain, I would like to add a few points to my view.
(1) The POW system does not assume “trust majority honest”, it does not need such an assumption. It just assumes that every human node is selfish, just like the basic assumption of economics. The security of blockchain comes from probability and benefit-cost ratio.
(2) The POW system achieves this through features such as forking, non-finality, and open nodes. Thousands of non-consensus nodes, although not involved in consensus, have the ability to verify data and the power to choose. When most of the consensus nodes are found to be dishonest, some of the non-consensus nodes will join the consensus nodes, some may not accept the longest attacked chain, but accept and support the shorter unattacked chain, and finally the market will reach a new consensus according to its “selfish” interest drive. Most of the dishonest nodes have to continuously maintain their computing power, which is a cost they cannot afford, and “sensible” cheaters will not choose to attack in this way.
(3) POS systems require the assumption of “trust majority honest”, but “open and verifiable block data” can minimize the damage caused when this assumption is broken. Because users know what is happening in time, they can take action as soon as possible. The worst case scenario is that everyone can leave the failed system as soon as possible. This in turn will exponentially increase the cost of their attacks, deterring most nodes from trying to attack from the cost factor.
(4) None of the new generation blockchain systems use the POW system, which in principle reduces security but increases efficiency, scalability and creativity, which is well worth it based on the goals pursued. However, many important security measures, such as publicly verifiable block data, cannot be easily discarded along with them.
A trustless system is one that assumes that anything can happen and is designed to make each path of attack sufficiently costly.
5 Likes
Evolution is, after all, amoral – there is no standard of ‘good’ or ‘bad’ beyond the blunt dictum: If it works, it persists; if it doesn’t, it disappears. Explaining the debate over GMOs—and what is or isn't 'natural'— through the genetics of chickens - Genetic Literacy Project
A little bit of exaggeration here, but would you let your friends eat chicken that are grown in a lab in a day or week? Well, with your argument it seems that as far as they are living organisms (chickens) then a chicken is a chicken. But it would be nice for their health if they had a farm grown chicken that grows naturally.
That being said, there are other blockchains that are open that you can participate in/on. Why do you double down on the IC?
The math will reveal itself when it is the right time. For now just let developers work at their pace.
My native language is not English. Please focus on the main point I’m going to make and don’t dispute some words, it’s pointless. If you have this idea, you can find many points to dispute. Some arguments are just to make my point.
this is not about " morality ", this is about blockchain !
“Morality” is used to discipline oneself, not to kidnap others.
I have been involved in the debate on this topic. Discussion: public subnets
Is it possible to make a point here normally? Don’t try to convince the other person if they have a different point of view. I would like to hear other people’s views. I won’t continue to reply in this posting.
2 Likes
Excellent post, @bitbruce - worthy of reading no matter which side you are on in this debate. I’ve just highlighted one key point, but all your points are food for more thought.
Everyone tends to get caught up on all the qualities that a blockchain should or must have. However, if you examine all those qualities closely, they are generally driven by the same fundamental criterion: decentralization of power. All infrastructure dysfunction, socioeconomic dysfunction, environmental dysfunction, etc. can be traced to centralization of power inevitably leading to abuse of power and injustice against those without power (or with significantly less). Even when power can be successfully atomized via blockchain (for infrastructure) or DAOs (for human organization), there is still a very large collective power that needs to be verifiable as an internal control measure. And I think that is one key point (among others) that @bitbruce is highlighting here.
As a result, I think there needs to be a roadmap towards some sort of blockchain verifiability process, which will preferably have no discernible impact on data privacy or network performance. I suggested an analogous “Wayback Machine” of blockchain history that could at least be verified after the fact. If this is too cumbersome, then how about statistically significant random samples of blockchain segments that can be periodically verified by the public? If public verification exposes too much data, then how about an NNS-appointed blockchain auditor (or multiple auditors) to issue periodic verification reports? Again, such an internal control may not be critical now. However, when billions of dollars are at stake on the IC - thereby creating much higher motives to exploit centralized points of failure - I agree that the market will likely not be satisfied with a moon math black box, no matter how reliable it has been in the past (or is statistically projected to be in the future).
I don’t have enough expertise to assess the reasonableness of ideas to address this issue. However, more ideas would clearly be helpful to find a potential solution to an understandable market need, even if this need is just “perceived” and not statistically necessary (per Dom). So I will continue to throw out what ideas come to my mind based on my limited background and experiences, even though most of my ideas may not be viable.
OK, I’ll bite. You mean in the same way in which most of the market does not trust HTTPS for credit card transactions?
And if you e.g. don’t trust the IC’s use of “moon math black box” threshold signatures, how could you possibly trust that I (or anyone else) cannot hijack a single boundary node and inject a fake response that appears to be signed by the NNS? (As in “yes, that ICP you requested just got transferred to your wallet”.) If that were possible, there would be no need whatsoever to hijack two thirds of a subnet’s replicas, just pretend to be the subnet.
I have asked this before and never got an answer. How is this different from the same NNS “appointing” one more replica to said subnet? A replica belonging to an auditor. Because that is essentially what every node operator is, an auditor that ensures the rules of the protocol are being followed. All the actual work done by an IC subnet can be more efficiently handled by a single replica. All the other 40+ NNS replicas are quite literally NNS-appointed blockchain auditors.
3 Likes
It may not be that different. But how many independent auditors are auditing the IC blockchain today and issuing audit reports on the integrity of the calculations, which they will need to replicate to validate? If no one in the general public can verify the calculations are correct and consistent over time, then how can I get some independent assurance that my hypothetical billion dollars of ICP or intellectual property on the IC is safe? In other words, if funding a replica for an NNS-approved auditor is an easy solution to the verifiability problem, then just say so. We can then put the verifiability problem on the backburner until the stakes become sufficiently high to warrant a proposal to fund this continuing cost.
Because no one else has my private keys, which are only in my hardware wallet. Like when I transfer BTC, I should not need to trust boundary nodes or even HTTPS to transfer ICP. However, unless I’m severely mistaken somehow, what I do need to trust are the blockchain calculations protecting my hypothetical billion dollars of ICP or intellectual property on the blockchain. That means some sort of verifiability should be in place to justify or remove this trust, just like the collective trust in the BTC blockchain is justified / removable by the ability to validate the BTC blockchain calculations. I say “justified / removable”, since, for the vast majority of people, that trust will merely be “justified” by the fact that it is “removable” by a sufficient number of independent experts on a continuous basis.
EDIT: I have one additional point to follow on my last two words of “continuous basis”. For BTC, this continual ability to verify calculations is there, but it is not that important, since the BTC blockchain code is not changing. For the IC, however, its code is constantly changing with frequent updates. The general public has no way to validate the internal controls over developer access to change that code, in spite of the required NNS approval. That’s why it is even more important to be able to verify the IC blockchain calculations on a continuous basis, at least in my view.
1 Like
Your ICP may well be safe. But if I’m supposed to transfer you some ICP and I can pretend to be the NNS (by faking a response and signing it with the NNS’ private key; which should be doable according to you, if all that’s protecting it is “moon math”); then I don’t even need to bother taking control of the NNS. I can simply hack into the one boundary node that you connect to (or, if you talk directly to a replica, then that one replica); and whenever you query your ICP balance and list of transactions I can make it look like I’ve transferred the ICP I was supposed to. And no auditor is going to notice that, because I haven’t even bothered touching the state of the NNS, I merely invented a response to your query only.
The Bitcoin equivalent would be that whenever you query your Bitcoin balance, I can quickly make up a few Bitcoin blocks with valid hashes that show me having transferred you any Bitcoin amount I want.
If you trust the latter to not happen, why don’t you trust the former? Isn’t the latter also “moon math”?
No, that was never my assertion. If a single replica can never be sufficient for audit purposes because it can be faked via human intervention or some other means, then your implied suggestion (not mine) to use a replica was simply wrong and misguided. Another solution would be required to allow verifiability of the calculations.
Also, if you don’t like the term “moon math” or the lack of verifiability that it implies, then perhaps Dominic should stop using it. That term is not something I would personally use to describe how the IC protects billions of dollars in future assets without any planned ability to independently and continuously audit either the assets or how they are protected.
It is not about the verifiability of calculations. That’s what I keep saying. You can verify the correctness of the subnet all you want; and the subnet may behave perfectly correctly; but if I can fake a response from said subnet (which is trivial if I can get control of 9 out of 13 replicas on the average subnet; or 27 of the 40 NNS replicas) then I can make you believe whatever I want, without anyone else (auditor or otherwise) ever having a clue about it.
At that point, I don’t even have to fool you. I can simply fool any canister on any other subnet (pretending to be the subnet I just hijacked), lying to it about the contents of the ledger, registry, or whatever else (e.g. “free just transferred Sabr 1000 ICP, please hand over the corresponding amount of Bitcoin”).
All without even trying to mess with the correctness of any subnet. Looking at any one subnet’s blockchain in isolation, everything would look perfectly legitimate.
And the above is just one example of how things could go horribly wrong if we assume that the only way one could trust a subnet is to validate every single block; with everything apart from that nice to have, but not trustworthy.
2 Likes
Why would an independent auditor validate only one subnet or node if this is not a reliable verification procedure? Similarly, if it is “trivial” for someone to compromise 9 or even 27+ nodes on a single subnet as you shockingly imply, then why would any blockchain auditor rely on only one subnet? Again, I never once suggested such a limited approach. An auditor would need to audit a majority, or at least a statistically relevant sampling, of nodes - and in sufficiently multiple subnets - to ensure that the blockchain data being audited is valid first. And only then would he, she or it (i.e., an offline program) audit the blockchain calculations to verify the blocks have not been collectively tampered with or calculated/hashed incorrectly. This could be due to a subtle error in the math not caught by NNS mass approval or due to malicious code inserted via a developer backdoor that no one else knows about.
Again, we are talking about billions of dollars in future value here, all of which could go up in smoke with only one such error, especially if it is allowed to multiply unnoticed / unaudited over a long period of time. I have seen nothing in this thread that could give me comfort that my hypothetical billions could ever be verified as secure at any recent point in time. I can accept that real-time security requires some transitory trust in the calculations being correct and consistent with the past. However, I (and many others) would not be able to accept a permanent inability to independently verify my assets and what blockchain calculations have recently been in place to protect them.
It’s the same concept why we are willing to trust the transitory quarterly releases of financial statements for public companies as long as there is also an annual financial audit. Forget about all the technical restrictions for a second and think about the market need for this basic level of independent assurance and whether the IC has any current procedure or plan to deliver that assurance.
The other extreme of requiring the ability to “validate every single block” (i.e., across all nodes and all subnets since genesis) to get this assurance is not what I was suggesting either. This is not how independent audits are even conducted. To me, it sounds like you are basically arguing against two strawmen of your own creation. If DFINITY can’t first acknowledge the very real market need for some basic independent assurance and come up with a viable solution that doesn’t break something else, then at least frankly admit that no acceptable solution to address this need will ever exist under the current IC architecture.
1 Like
@free, if I may summarize what you are saying:
- Publicly verifiable block chain data only goes so far to ensure safety, because things could also go horribly wrong (and undetected) even when everything is publicly verifiable.
- “Trusting majority of nodes are honest” is an important assumption that lies behind the security promise of all blockchains, including BTC & ETH.
I think you are concluding that since we need to “trust majority honest” anyway, “verifiability” doesn’t bring much additional benefit?
I tend to agree with both 1 & 2, but I’m not sure if I want to agree with this conclusion.
5 Likes
I agree that such a conclusion does not follow from the assumptions. Keep in mind that at least two things need to be verified, not just one:
- statistically sufficient (or majority) consistency among the nodes, and
- whether the blocks are being correctly calculated / added to the chain.
For #1, this should be relatively easy, even for BTC, with statistically random sampling across a few thousand nodes for a high probability of assurance over consistency. For #2, random sampling of a few thousand blocks and independently recalculating them could likewise provide a high probability of assurance that the calculations are both correct and consistent, since even one deviation would indicate an unacceptable level of error. If it is possible to get this assurance from one blockchain but not another, then there is indeed a large difference in verifiability benefit between these blockchains.
Why have we devolved into man-in-the-middle attacks which any blockchain is susceptible to?
The original ask is to PROVE TO EVERYONE that the IC is doing what it says it is. That’s it.
We have many papers, blogs, and many tirades asserting what the IC does, but no PROOF that actual node machines are running what they say they are. I could go on all day about this. How is the data from dashboard.internetcomputer.org populated? Why can I not query for this data? Unless, of course, I can- in which case please correct me. But it seems to me that certain data about the IC network is privileged. How is that fostering an open alternative to the internet?
Perhaps querying one boundary node is not sufficient. Ok. So let’s query a bunch, and achieve a consensus to guard against Byzantine faults and compromised nodes.
The entire reason anybody wants this is because we, as a community, have NO way to peer into the inner-workings of the IC, other than, as Dom says, to interact with canisters. However, by your argument, we cannot ask for read-only canister state and state transition data because a boundary node could be corrupted. If that’s the case… then how can we trust the output of what the IC is doing at all??? By your logic, we should trust ABSOLUTELY NO OUTPUT from the IC, because a boundary node could return bad output.
Edit: I do not mean to come across as harsh, but I’m rather using forceful language to get questions answered.
5 Likes
@dominicwilliams @free I think we are all just trying understand how the IC replaces the security of users being able to locally run a node themselves. You’re saying “the math” is able to replace the security, but how exactly does “the math” replace it?
2 Likes