To be clear: a trustless solution is impossible; it would require implementing a Solana light client in an EVM smart contract.
A trust-minimised solution, while theoretically possible, is much more complex than you’re hand-waving it to be. Likely the best achievable solution is to use one of several decentralised oracle networks that already exist.
So there is a solution, even if that is “decentralised oracles”. I would consider it good news.
In any case, we will scale down this proposal significantly and attempt to create a trust-minimised messaging service first. Is this line of work something that you and @avsa be happy to support?
Yeah that would be a hard sell and would probably require a constitutional amendment and maybe a letter of no objection from ICANN. I said it was just my personal opinion.
I think looking for a solution to have data availability of ENS names on Solana using existing decentralized oracles, is something I would support and definitely a net benefit for both ENS and Solana.
Where has this number come from? Based on the following commentary this seems hyperbolic for impact but as mentioned below… is there a Solana ecosystem temperature check on this too?
This seems unnecessarily complex, but gameable (as mentioned by Nick).
This seems odd to me. Labs do operate some gateways, but in relation to my own interests (and I believe also the view of labs) gateways should be decentralised. But… I don’t know, something doesn’t sit quite right with the idea more generally. This is an ENS temperature checks but are the Solana ecosystem in favour of this?
That doesn’t actually seem feasible or realistic… as you mention.
This sounds interesting and is a novel concept but with its own complexities and intricacies that affect the user experience. The obvious ones being the latency of resolving from multiple gateways, and the gas costs/contract complexities of implementing this proposed slashing mechanism.
I do agree with this that with a lot of future looking development there is an element of ‘you don’t know if you don’t try’, but perhaps this should be the first milestone? because there is no point the DAO agreeing to funding milestones that can never realistically see production USE.
No…
Could anyone share any insight on how true this actually is? Its technically feasible to have .sol (I’m talking about on ENS here, not DNS)
I’m not saying this is not true, I do not know… but there are an abundance of possible reasons for a Solana presence in Denver.
That said, I have personally only heard good things about the vibe surrounding Solana ecosystem participants attending ETH events.
–
I respect the time, thought, and passion that has gone into this temperature check but personally I don’t see it having real legs at this time.
It is shown in the calculations step by step. No information is lacking that leads to this number.
The entire stack to make this work already exists:
I only said that it was complex, never unrealistic or impossible. I have a feeling that people in ENS developer circle are really behind on their research.
Rest can be fixed. We’d give it an honest try.
That’s what this proposal will be scaled down to.
I mean… people are busy. We have our own focus areas and mandates so realistically cannot keep up to date on all research in all areas. Given that, I think it is reasonable to expect proposals to contain (and link to) appropriate/relevant research.
It’s your area though. The link I shared is of an SVM L2 on Ethereum. Last I checked, L2s were your paradigm. Please rethink your approach when you declare things impossible without doing due research.
Quasi-L2 setup wasn’t part of this proposal since we were quite certain (and wrongly so!) of the DAO-controlled gateway approach. These methods will be part of the scaled down proposal though which will concentrate on trust-minimised setup.
We are submitting our proposal to Solana Foundation as well. We’ll keep everyone posted how it goes.
Nobody said you can’t build an SVM-based L2. But you’re not proposing to bridge to that, you’re proposing to bridge to Solana. The VM is not the issue there, trustlessly proving state is.
We have already agreed that trustless is not possible. This was a comment on Method 2, which is a trust-minimised example. The idea is to use the same state indexing as Eclipse and use a decentralised oracle as the messaging service (your idea!). That’s the outline of a “trust-minimised Solana bridge to Ethereum using decentralised oracles”. SVM state indexing is part of the equation. It is not impossible or unrealistic.
Gateway multi-sig example isn’t half as bad either. Since gateways can interact offchain, there are many interactive ZK methods to ensure relative gateway integrity. You can also prove or disprove their relative integrity using FHE challenges. This will also be part of the scaled down proposal.