I have been considering doing a parachain for Solana to have a Solana VM pallet which could support Solana smart contracts.
Given that rbpf (GitHub - solana-labs/rbpf: Rust virtual machine and JIT compiler for eBPF programs) is already written in Rust which makes it pretty realistic to compile into WebAssembly, a nicely optimized WASM RBPF VM seem that it could have value for interoperability, then account mapping would be left and probably some other things that I forgot too.
Having SVM support on Polkadot seems like a more natural choice, than SVM support on EVM by far - but would there be any benefits?
My understand is that performance wise Polkadot VM is superior to Solana’s, but there are other parameters.
What do you think would be the pros and cons, and more importantly is there any benefit in something like this, is anyone interesting in working on this too?
eBPF works great for what it was designed for by Kernel folks. It’s not a natural choice for smart contracts however.
My understand is that performance wise Polkadot VM is superior to Solana’s, but there are other parameters.
Even if you somehow were to get compatible implementations of their account model and parallel transaction model in your runtime. A Solana VM parachain would still be slower than Solana mainnet. They have high hardware requirements on nodes; this and parallel contract execution giving them “high TPS” despite eBPF.
Also I’m not exactly sure what you are referring to with “Polkadot VM”. Roughly, Polkadot as a sharded system scales horizontally where Solana scales vertically.
account mapping would be left and probably some other things that I forgot too
I think that you’d want a “Solana on Polkadot” to be fully compatible, i.e. shipping with a “frontier for Solana” compatibility layer. Otherwise you’d offer the same but worse in many ways (i.e. worse performance, not fully compatible, you aren’t mainnet making it more annoying and costly to interact with their ecosystem. EDIT: Decentralization, resilience and uptime would of course be much better than on mainnet, but at this point we see that the Solana ecosystem couldn’t care less about those factors anyways). I don’t see Solanas tech stack and standards being that relevant in web3, at least in no way as relevant as ETH.
What do you mean by “Frontier for Solana”? Yeah, in the context of “Solana on ETH”, performances are definitely more significant.
I’ll continue playing with the rbpf VM for now, as yeah it’s not very clear if there would be significant advantages in the future if that was possible.
Awesome, I don’t know Solana inner workings in detail; like to see experiments like this being carried out! Looking forward to hear more about any findings
What do you mean by “Frontier for Solana”
A compatibility layer that makes a Substrate node look like a Solana node so that existing infrastructure (dApps, tooling, wallets, etc.) work just fine. For ETH next to an EVM this includes things like RPC endpoints, compatibility with their gas model, account format, transaction receipts and so on.
would be really interesting to see this, as I think long-term there there is a chance that it becomes a supported service in Polkadot 2.0. And more near-term research in that direction would be great.
What’s your experience with Solana smart contracts?
Despite the lower performance on Polkadot (purely based on hardware) and despite the fact that it may not be the long term solution (compared to RISC-V), there would still likely be value in building a SVM on Polkadot. Given Polkadot SDK is at the chain level, we have the unique capability to copy other VM designs (EVM, CosmWASM, Move, etc.). I think we would want to be able to market whatever they can build so can we (plus more).
Thanks all for your answers! It sounds it’s an idea definitely worth pursuing, and I’ll spend more time looking into it. If anyone is interested in helping my Telegram username is the same as here
You could build a Substrate solochain with Solana compatibility and beefy collators that submits bulk transactions via proofs to an existing Parachain for finality.
Could be a failover for when Solana transactions start to fail like a throttling mechanism for Solana to relieve congestion but would involve a trustless component of some sort.
I first thought they were aiming for this only when i started reading the post,
I would be really interested to see such integrations especially for devs to switch
With the latest Solana congestion drama in mind. It’d be interesting to think about how a “Solana on Polkadot” could use Polkadot scaling mechanisms, i.e. using multiple cores.
Another thing to keep in mind is how “fragmented liquidity” became hot in the ETH world lately as they are now deploying many L2s. Solana doesn’t have this problem but I think that without a clear idea how “Solana on Polkadot” would communicate with their mainnet it seems we’d be doomed to face the same, basically competing with them which I sense as rather undesirable outcome.
I just wanted to point out that in order to create something actually valuable, I anticipate this to be more work than just making e/rBPF contracts run inside a parachain runtime Again, with that said, I think this is definitively a very interesting endeavor and I’m very happy to see developments in this direction.
I’d suggest folks ignore solana as a smart contract platform: If smart contracts are for immature projects, then we’d maybe prefer smart contract projects on polkadot develop along the lines we favor.
Instead, we could provide grant money for porting solana’s rust sdk to be frame pallets. In this way, an established solana project could port their smart contract code into being a full parachain more easily, after which they benefit from elastic scaling, etc.
Also…
We solve scaling problems for full chains in polkadot, but there exist many scaling footguns for smart contracts beyond the problems beyond those for full chains, some of which even look computationally intractable. If you’ve hit smart contract scaling problems, then just becoming a parachain could break inefficent interactiosn with other projects’ contracts, and/or give you better storage optimization options.
You mean that instead of doing an SVM as a pallet, to directly port the SDK? I don’t know why I didn’t think about it. This could also have some great security benefit as it would definitely allow more tracing for contracts.
The part where I would say it’s not necessarily a purely dev tooling problem, is that if you only port the SDK, you may not have account mapping between the two chains. Although, I agree this itself would come with its benefits and problems.
I’d be interesting in discussing and exploring this idea more.
I’ve heard solana does not merkelize their state, which should doom most cross chain ideas, like bridges, etc, but maybe some vlaue in the code for some popular app.
