Hello. @graphomath asked me about Rome, a framework for converting EVM/solidity contracts into a form that works on Solana. Right now, we have a working version of the PA for Solana. If we used Rome, all that would be scrapped in favor of a new, smaller implementation. The goal of this post is simply to state pros and cons of doing this. This is based on reading documentation; I did not see anything worth attempting to play around with on its own merits.
Firstly, what exactly does Rome do? In essence, it’s a Solana contract which contains an EVM bytecode interpreter. The Rome EVM is publicly available here. In principle, it allows you to deploy and run an EVM solidity program on Solana. Actually making the EVM PA run on Solana via Rome seems, on paper, as simple as existing work getting the EVM PA working on different EVM chains. Since Rome would essentially create a new EVM chain, basic implementation would be approximately as difficult as it was to extend to the current list of targets. This will NOT be sufficient for usability on Solana, though (see below).
There’s not enough public to deploy the EVM ourselves; this lacks several parts of the on-chain program, such as the Solana Address ↔ EVM address mapping. There is a secondary layer for indexing and facilitating communication between EVM wallets and the Solana program which is not public. We’d have to maintain our own versions if we did deploy it ourselves, which is more work than the Solana PA itself was to make. Using the Rome EVM would essentially involve asking the Rome company to deploy and keep up the second layer. So using Rome implicitly assumes its worth trading the sovereignty cost; Solana support would perpetually depend on the Rome company.
The Rome concept also leads to some fundamental limitations to the PA which may not be desirable. Proper Solana-based forwarders are essentially impossible. For example, forwarders would need to be implemented in Solidity against Rome’s CPI, and there would be no meaningful sense in which we have Solana native forwarders. If we are fine forcing developers to make forwarders for the EVM, then fine, I guess, but why are we putting ARM on Solana to begin with if we are excluding the Solana ecosystem? Maybe this could be kind of alleviated with a shim?
To what extent does Rome put EVM programs on Solana? That is, to what extent can a Solana user use a Rome app without having to think about Ethereum? For a narrow class of apps which are essentially send only, such as DEX swaps or lender deposits, this works fine and you can drive a contract with a Solana or Etherium wallet. This is what their demos show. However, Solana doesn’t have Permit2, which underlies Anomapay. This is already solved in the Solana PA with an alternative equivalent, but the reality is that you cannot drive the EVM version of Anomapay using the weaker information a Solana wallet provides. Though I can’t quite articulate all the changes needed, it seems possible to fix this by altering how Anomapay works. Since it was solved on the Solana side, there intuitively should exist some neutral version that works for either; though I don’t think what the Solana PA does is directly translatable since it doesn’t seem the EVM has good support for all the used primitives. This is all to say, we would be giving ourselves a new engineering project whose solution is not clear. Because of the needed changes, it’s not going to be the case that we can simply put the EVM PA on solana and have it work. We can do that, but it would be unusable for an actual Solana user.
Also, this would be WAY more expensive than the native PA. I think that would be obvious, but it’s worth saying. How much more expensive isn’t clear from the documentation I read, but I would guess several times.
So, should we use Rome? This is a management decision which requires PA owners to affirm the purpose of the PA, and the purpose of putting the PA on Solana. If it is to give proper support for ARM within the Solana ecosystem, that’s simply not what Rome allows. But there are reasons to use it; if we don’t actually care about the Solana ecosystem, or Solana developers using the PA using their preferred tools, for example. Even then, we’d have to seriously modify the EVM PA anyway.