Does Ethereum’s amorphous timeline on shifting to proof of stake have any impact on the feasibility of integrating the IC w/ the ETH network?
It shouldn’t. There are a couple of layers of integration(if you go back and read Dom’s initial post you’ll see them). Eth transactions are just transactions. As soon as the IC can create a stable address and sign as that address you have the first layer of integration. That can be augmented by making ETH chain data reliably available on the IC, but you don’t actually need it if you have another way of trusting the state that you think you have. If you can interact with near real-time state then you have many more types of applications that you can build, but there will be plenty of applications once you can just produce addresses and sign.
Think of a multi-sig wallet that runs on the IC that issues a send transaction on the ETH chain. It really doesn’t need any info from the ETH chain. Sure, knowing the balance, would keep you from issuing a transaction that spends more than you have, but even if you issue a transaction for more than you balance it will just fail. You can use this same logic to build things like a DEX where you provide a Merkle proof of your deposit into the on IC-ETH addressed canister and then the canister can assume it has control of that Token until it sends it to another address. The on IC dex can operate without gas fees and just needs gas to send withdrawals back to other ETH addresses.
None of those applications require you to know anything about how the ETH consensus mechanism actually works…or event to know the real-time scope of the state of the ETH chain. You don’t need those things…but it would be cooler if you did have them!
Wow, that’s a great explanation; thank you!
Before ETH integration, we should maybe integrate Bitcoin derived Blockchain… Because these blockchain have NO SMART contract, NO POSSIBILITY of Swap… imagine if you can REALLY hold BTC, BCH, LTC, DOGE, DASH on ICP… The, it will be able to create contract to swap BCH for LTC… Amazing… I think all Bitcoin fork should be integrated first on ICP as it could require minimum work once it’s done for Bitcoin first. Could this proposal be added ? I am sorry I am not native english but if someone can formulate it properly in english, it would be nice.
I think this is very reasonable, DeFi for all the Bitcoin forks!
Afaik BCH has some smart contract functionality, anyway I’d rather have ETH and the immense erc ecosystem on the IC than some old chains nobody cares about.
I am pretty sure this has been asked before, but can someone ELI5 why a direct integration of Bitcoin with Ethereum is not possible/feasible?
A direct integration of Bitcoin with Ethereum means that a smart contract on Ethereum can “natively hold” Bitcoin.
That means that a smart contract on Ethereum can hold a Bitcoin private key, and sign Bitcoin transactions using that private key.
For that to work on a decentralized computer, you need to split up the private key into “shares” and distribute it across many Ethereum miners. Then, when that smart contract wants to make a transaction on the Bitcoin network, each miner will need to sign the transaction with their own private key share, and if and only if a sufficient number of miners sign will the transaction go through. This is known as a “threshold signature”.
Another problem to solve: who actually generates and securely distributes the private key shares to the miners?
All of this is non-trivial to implement. In the case of Ethereum, I don’t know if it could even work, because everything on the Ethereum blockchain is public, and any node can read the contents of the entire blockchain. That means private key shares cannot be made private or secret.
Also, there are many more Ethereum miners and nodes participating in consensus than in the IC, since the IC blockchain is split into smaller blockchains, each reaching their own independent consensuses. Can a 2/3 threshold ever be reached in Ethereum? What if a miner is given a private key share (that is somehow made private), but that miner goes down and never comes back online? What happens to that key share? On the IC, nodes remain online continually and are penalized by the NNS for failing to meet certain SLAs. Ethereum has no such guarantees that its miners will remain online.
There are probably more, but this is my understanding of why a Bitcoin direct integration will never happen on Ethereum, at least not in the next couple of years. I’m no cryptography expert, so it’d be nice if someone else with more experience could chime in.
Thanks for the explanation!
So you are saying that for the IC, any node can not read the entire chain? Can you give me a reference as to how this works for the IC?
Thanks again! I hope more people will want to say something about why direct integration of Bitcoin with Ethereum is not feasible!
Check the section “Scaling out infinitely” here: Chain Key Cryptography: The Scientific Breakthrough Behind the Internet Computer | by DFINITY | The Internet Computer Review | Medium
Does a subnet threshold signature carry the same security guarantees as a zk-SNARK though? A subnet threshold signature proof is only as secure as the subnet, which may be compromised if 2/3 of the nodes are malicious.
A zk-SNARK proof is only as secure as… mathematics? This part I don’t know. Can a zk-SNARK generated by a single node really be secure? I suppose the proof guarantees that the node couldn’t have fudged the results?
But the tradeoff seems to be that zk-SNARKs are expensive to generate, so expensive that you can’t generate one for every transaction. Instead, a bunch of transactions need to be batched by an IC replica, for example, and consensus is needed to agree on the order of the transactions in the batch (as @lastmjs explained to me). If it weren’t for this computational limitation (which one day may be removed thanks to math), it seems to me that blockchain-based consensus might… not be needed anymore? Or am I totally crazy?
Dominic wrote in the article cited by OP:
- Ethereum and the Internet Computer are different beasts, which derives from their respective focuses. You cannot transform one into the other owing to technical considerations. They are different by design, but very complementary — not competitive. The Internet Computer is hosted by special node machines run by independent node providers in independent data centers around the world. By contrast, anyone can create a block-making Ethereum node using a graphics card and run it from home. You need both architectures in the world, for technical reasons I will not go into here, and they produce different and complementary properties.
With Ethereum now moving closer to PoS and in consideration of the Badlands initiative for the IC, does the Dfinity team feel confident that Ethereum will continue to fulfill an important role in the IC ecosystem?
I understand that Bitcoin has a special status deriving from its deflationary properties as a store of value, decentralized nature, and first-mover origin. I’m happy about the Bitcoin integration initiative and excited to see that this difficult and complex process is nearing finality. I’m curious to know however, in layman’s terms, what Ethereum integration offers the Internet Computer that it will not eventually have on its own.
To be clear, I’m aware of the large and pre-developed ecosystem and user base that can be gained from ETH integration. I also understand that Dominic has a personal history with Ethereum and respect for what it has accomplished. But are there any core competencies that Ethereum integration can still be expected to bring to the IC ten years from now?
That’s a good question. A zk-SNARK system can be considered more secure because nodes cannot lie about statements that they prove: If the system is in a valid state and there is a proof that transitions are executed correctly, the system must remain in a valid state.
By contrast, if two thirds of the nodes in a subnet are malicious, they can change the state arbitrarily and provide arbitrary responses without detection.
However, it’s important to note that there is a need to agree on an order of transactions/state transitions with or without zk-SNARKs, so some sort of consensus mechanism is needed anyway.
Moreover, as you mentioned, zk-SNARKs are computationally expensive.
In the future, we might have subnets with different security guarantees. For example, a subnet might make use of secure enclaves to protect the confidentiality of computation and canister data. For highly sensitive applications, this might not be considered secure enough, in which case you’d want to run them on subnets making use of zk-SNARKS or maybe even fully homomorphic encryption.
These topics are actively being investigated (but in early stages ).
You are right that bringing the two worlds closer together, in order to tap into the large Ethereum ecosystem and user base as well as to enrich the Ethereum ecosystem, is currently the main driver behind he planned Ethereum integration.
Superficially, it may look like there is little additional gain as the Internet Computer can do what Ethereum can do and a lot more but it’s impossible to know what innovation we will see in the more distant future (on both platforms). Ideally, the integration will make it possible to benefit from any new developments also ten years from now and beyond.
ETH will probably always be more decentralized/secure than an IC subnet.
I’m going to strongly disagree.
Ethereum appears at risk of getting kicked off the cloud-networking provider that powers roughly 16% of the second-biggest blockchain.
If Ethereum is forced off Hetzner, it would further whittle down where it resides, raising the question of just how decentralized the purportedly decentralized blockchain really is. According to ethernodes.org, over 60% of Ethereum nodes – the computers that process transactions on the network – are hosted by cloud service providers. Of these cloud-hosted Ethereum nodes, Hetzner powers roughly 16%, second only to Amazon Web Services at around 53%. (ISPs - ethernodes.org - The Ethereum Network & Node Explorer)
We don’t even suffer from these problems… I also heard 20% of eth validators will refuse to process tornado cash transactions. Eth is looking wobbly compared to our warming charm that is the IC
I hear this a lot and I frankly think “the jury is still out” on this. Dfinity has been pretty vocal about its thesis (right or wrong) that maximizing the vector of node providers, the countries, the data centers deterministically will Lead to more decentralization properties folks want when they say “we want decentralization.”
Not sure how numbers have changed after the merge, but back before the merge, it would only take a few node whales to (some would argue as small as four) to create 51% consensus… yes, just four. This means ghat the hundreds or thousands of other ETH nodes create a node perception of ”decreased concentration”, but the true is that a few whales could sway consensus.
Is the design of deterministic decentralization better than ETH? I think realistically, we do not know yet:
- Post-merge ETH may have less concentration of nodes
- deterministic decentralization is far from implemented in the IC NNS so hard to gauge
- I believe not enough time has passed to see how different networks deal with different attacks
- the measure of what is better depends on whether one cares more about liveness, cost, censorship resistance, minimum number of entities needed to sway consensus, and other variables
- we may see less or more concentration in ETH as time Goes on
- once SEV becomes online, it may lead to better security from nodes… even if subnets are still small in comparison
I can appreciate how some folks have made up their mind that ETH style (“everything goes”) vs “deterministically decentralize” leads to better outcomes, but I still lean towards a “I believe in dfinity’s thesis… but I honestly think not enough data has been accumulated to make an obvious case.”
One doubt I have about a permissioned network is I don’t know if it’s possible to take every possible variable into consideration when deterministically decentralizing the nodes. Permissionless networks will theoretically automatically decentralize nodes by every variable overtime. Permisssed networks may not ever be able to do that, for example does Dfinity take into account ASNs (ISPs) when decentralizing nodes?
It has been my experience and observation that the opposite happens quite often in crypto networks… compound effects take in and there is lots of concentration for certain parts of the decentralization vectors (not all). But I hesitate to say that is an immutable law, more of my current thesis (which could be wrong).
Deterministic decentralization trades the statistical safety provided by sheer amount of nodes for less nodes but following certain metrics.
What these metrics are and how they are verified are the weak points of DD.
- All nodes must go through KYC
- All nodes must be hosted in Data Centers
These 2 alone are enough to make DD inferior, all it takes is for the leading countries (US, Cina, Russia, etc…) to agree on some rules and all the other countries will follow, meaning unless you want nodes to be run only in a handful of states you’ve never heard of, the network might be decentralized on paper and offer some degree of trustlessness but will ultimately have to comply with the status quo.
The KYC process required to join the network is also problematic:
How does the NNS verify the trustworthiness of a specific node provider? I’m sure Dfinity took a lot of time and effort to verify the initial node providers, possibly giving access to entities which they knew could be trusted based on first hand experience. I doubt the NNS can do such a good job.
Providers will also have to publicly provide personal information so they can be vetted, the more they give out the more their level of trustworthiness can be guaranteed, but by doing so they also expose themselves and frankly speaking I doubt doxing themselves is worth it.
If I wanted to attack the network it wouldn’t be too hard to set up a couple fake LLCs owned by a figurehead, money needed for hardware and server space is the only limiting factor.
It is my opinion Dfinity started on the wrong side of the decentralization spectrum, if ETH maximized decentralization and is now focusing on scalability, ICP decided to be as scalable as possible and then gradually work towards decentralization, the reason why I think it was the wrong choice is the scalability provided by this tradeoff isn’t that great all things considered: nodes cost up to 28k$, they must reside in data centers and subnets have only 13 of them, yet a subnet can only do 1k tps at the moment.
Decentralization MIGHT improve in the future but nobody knows to what degree, it’s hard to decentralize when the subnet’s performance degrades with node count and the network relies on the assumption of permissioned and KYCed nodes.
To be clear I’m not saying the current topology of the network is bad, the IC wants to become a viable decentralized alternative to centralized cloud and you can’t run the internet using raspberries on residential connection, but not all apps are the same: some might be more data or CPU intensive (Youtube, Twitch, etc…) and require less decentralization, others need a high degree of decentralization and are light to run (DeFi, ledgers, NNS, etc…), the problem is IC only accounts for the former (kind of) and it isn’t clear if and when the latter will have subnets suited for them.