# Ethereum RPC Compatibility for Polkadot Smart Contracts **URL:** \ **Category:** Tech Talk\ **Tags:** smart-contracts, ethereum\ **Created:** [April 10, 2024, 11:33am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375 "2024-04-10T11:33:57Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![sasha](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sasha/32/4694_2.png) [@sasha](https://forum.polkadot.network/u/sasha)\ **Post date:** [April 10, 2024, 11:33am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/1 "2024-04-10T11:33:57Z")
The idea of making _pallet-contracts_ Ethereum RPC compatible has been around for a while. I did some research on the topic and built a working prototype which can be found in [this repo](https://github.com/agryaznov/ethink). This post describes briefly the approach taken to the problem, the results so far and possible vector of further development. Your feedback is very welcomed! ## Rationale We have the most technically developed blockchain platform, but lack of real users. The largest user base stays in Ethereum. So the ultimate objective of this project is to empower onboarding these users to our ecosystem. One obvious way of doing so is to migrate the beloved and popular Ethereum dapps onto Polkadot. This basically means to give the same user interfaces and UX, while providing cheaper and faster execution layer, with further possibly unlocked richer functionality, thanks to Polkadot’s unique cross-chain interactions like XCM and bridges. Technically-wise, there is nothing special in Ethereum what can’t be built on Polkadot, which provides way more features and agility to developers. Therefore, in essence there is (theoretically) no insurmountable constraints for porting Ethereum dapps (read: their users) to our ecosystem. What we need to deal with here is user _inertia_. The less user has to change in her basic journey experience, the better for getting her come here. At this point a meticulous reader may say: well, we’ve already been through this. We even have fully compatible EVM parachains. Where users? Well, true, there is an EVM-based parachain. Still it looks like just porting EVM to Polkadot (with performance downsides) is not really enough to make a breakthrough. Our contracts engine [had proven](https://medium.com/pendulum-chain/solidity-smart-contracts-on-polkadot-b49a648284ec) to be faster, and going to become ultra faster with coming support for the [new ISA](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811/1). We want to leverage this advantage to attract more users. Yes, we also got a parachain having both _pallet-contracts_ and _pallet-evm_ aboard. But while it tends to provide interoperability between contracts running on these separate engines, from the user perspective this is not going to bring more performance. And from the developer perspective it makes apps much more complicated to build. The idea of the project introduced here is to make Polkadot dapps Ethereum RPC compatible _without_ taking the EVM part of the deal. Let’s have a look on how’s that possible. ## Compatibility Decoded Consider a typical dapp tech stack: ![ethink-post-1_1](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/7/701c677cd6c5ad4405220db1a18e07e40af8559f.png) Simply put, there are the following layers of it: - UI built with _web3js_ libraries, - `RPC` exposed by a chain node, - `EXEC` Contracts execution engine, - `CHAIN` protocol logic, When we want to port an Ethereum dapp to our Substrate-based chain, we need to make sure that: 1. We expose the RPC endpoint which speaks to UI in compliance with the Ethereum RPC [spec](https://ethereum.github.io/execution-apis/api-documentation/). 2. On the Execution layer, this implies that our engine should allow contracts to implement the same business logic as in EVM contracts, while keeping the same calling conventions between caller and callee (more on that in the next section). 3. Aside from input and output of the contract being called, a dapp might rely on the underlying chain protocol data, such as block and transaction data, gas prices, storage state, etc. Now that we have pointed out what has to be done, let’s dive into how we try to achieve this. ## Solving The Puzzle As we’ve pointed out, just exposing the Ethereum-alike looking RPC is not enough. The underlying logic should comply with it as well (at least to a certain degree). For that the system must be able to be compatible to how things work in EVM on the layers below the RPC. First of which is the execution engine. ### Execution Layer Luckily for us, _pallet-contracts_ module of Substrate had been designed to be in feature-parity with EVM. Both are stack-based machines with gas metering, contract accounts are of the same nature as external (user) accounts (from the chain protocol perspective), there are constructors and call messages, payable and non-payable messages, as well as support for cross-contracts calls (both context-switching and delegated ones aka libraries), and overall its API allows implementing pretty much everything one would expect from an Ethereum smart contract. Still, there is one quite a sound discrepancy, which albeit do not really relate to the engine level. It is the way contract input data is encoded: Solidity contracts use ABI encoding, whereas ink! contracts use SCALE. But this is a _language_ level difference. On the lower, execution level, our contracts (both Wasm and RISC-V) accept input just as a byte sequence. How it’s being treated\decoded is determined by contract intrinsic logic, meaning contract developer can implement it in the way so that it works with ABI encoded data. Of course this would not be a very handy thing to do from the developer point of view, given no special tooling provided for that. But what’s important is that it is not an insurmountable obstacle, and we will talk a bit on how to deal with that further in this post. Next compatibility things refer to chain-specific data. ### Chain Layer Here it comes to the most noticeable difference between Polkadot and Ethereum building blocks: account format and crypto primitives: - Normally in Polkadot we use _32-bytes-long AccountId_ accompanied with _Schnorrkel/Ristretto sr25519_ algorithm for keys and signing, and _blake2_ for hashing. - Ethereum standard is _20-bytes-long AccountId_ and _ECDSA secp256k1 key pairs_ in combination with _keccak256_ hash function. There are more other discrepancies like e.g. the fact that extrinsic Id is not guaranteed to be unique between blocks in Substrate-based chains, while for Ethereum transactions that’s the fact on which a good part of business logic relies upon. Also, Ethereum has just gas for measuring computational effort, whereas in Polkadot we have two-dimensional weight, counting for execution time and for implied size of the proof data used by PVF. There are more other issues, but all of those seem to be surmountable (at least of this point of the research). As per _AccountId_, well… Polkadot was designed so that you can customize everything, and that unlocks some opportunities. First, nothing restricts your parachain from using whatever _AccountId_ and elliptic curves you want in your runtime’s business logic. More to that, _polkadot-sdk_ provides ready to use crypto primitives for this. Second, here we have to turn back to the objective we set at the beginning of this post, which is to get _existing_ Ethereum users aboard. And then we have to admit that users are not going to switch to other wallets/signing extensions right away, overnight. That means that for account format and keypairs we have to allow them keeping what they currently use. What we have listed in this section is not an exhaustive set of possible compatibility issues on the chain level, there might be others. For now in _ethink!_ some of RPC methods related to chain data are mocked, others return Substrate chain data. With the contracts tested so far, this looks like not a problem. In general, it should not be a showstopper, as in the worst case we could construct and store a fake Ethereum block for every Substrate block, this approach seems to work fine in Frontier-based chains. But again, the research is ongoing, and this would need to be tested in practice with porting real Ethereum dapps onto this solution. Finally, we can’t just wave a magic wand and solve the problem for all parties (users and developers) at once. Then let’s break it into steps, the roadmap of which could look like the one presented in the following section. ### The Road To All-Hands Compatibility As a first step, in short-term we may try to change as little as possible for the user, which naturally comes with the cost of additional work to be done by the dapp developer. In particular, to deal with ABI/SCALE encoding mismatch, as well as different message selectors, the frontend piece of the dapp would have to be modified to work with metadata of `a_contract.ink` instead of `a_contract.sol` one. Or, the contract piece of the dapp would have to be taught to deal with ABI encoding so that it takes the same input from the caller and returns the same output as the original Solidity contract does. In any case, unless we have a tooling for those things, the contract developer would have to re-write his Solidity contract in ink! by hand, which is totally feasible thing to do, as ink! was designed to have similar contract layout to Solidity, and if you look at its basic examples, you find a number of such ported contracts. Good news are that the tools for automation of such a translation are in active development: there is [solang](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949) compiler. I’m not sure if we are there yet, but once it’s ready, we take the second step, and let dapp developer just re-compile a Solidity contract source to be deployed to _pallet-contracts_. Last but not the least, some helpful tooling for developers, either for the ease of porting the frontend piece of dapp, or for making a contract deal with ABI-encoded input, could also possibly be provided. (At the end of the day, ink! contracts are basically Rust code, so chances are you could possibly use some existing crates for that). What’s being said could be summarized to the table: ![ethink-post-1_3](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/0/00a73e9c5608b3eff5b0892d6da5f7eda680c72f.png) Currently, we are in the first column, and it feels like starting entering to the second one (need to sync with @Cyrill and do some experiments with _solang_). Following this narrative, we may envision the target scenario as follows: > **Target Scenario:** > > 1. Take a successful Ethereum dapp. > > 2. Transcompile its contract from _Solidity_ to _Wasm/PolkaVM’s RISC-V_. > > 3. _[might not be needed]_ Port dapp frontend so that it deals with new metadata. > > 4. Deploy the contract to a parachain having _ethink!_ aboard. > > 5. Profit!! Now that we explained how we deal with particular compatibility issues, let’s have a look on how we bring all the pieces together to a running chain node which has _pallet-contracts_ and works with Metamask. ## High-level Design In a nutshell, _ethink!_ is like _Frontier_, but for _pallet-contracts_ instead of _pallet-evm_. Here is the simplified (non-exhaustive) components map to the compatibility layers introduced in the beginning of this post: ![ethink-post-1_2](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/0/0b069072cfb5e15071ce41af519f54130fb36e85.png) There are 3 main pieces of it: - `RPC` The RPC “frontier”, exposing the RPC endpoint which looks just like a normal Ethereum RPC. - `GLUE` The Runtime of our node, which provides special methods in its exposed API, gets calls from the RPC “frontier” and routes them further. - `EXEC` Execution of the contract happens in `pallet-contracts` module as usual. ### No Upstream Changes For all this stuff to work, no customization is required neither for _pallet-contracts_ nor for _ink!_. Polkadot-sdk overall, and its smart contracts stuff in particular, was designed with quite a good level of abstraction, allowing building such compatibility layers on top of it, with no tightly coupling to a particular execution environment. _(And this is what makes ethink! different to Frontier, which is tightly coupled to pallet-evm.)_ When it comes to tooling, in particular [cargo-contract](https://github.com/agryaznov/cargo-contract/tree/ethink) and [subxt](https://github.com/agryaznov/subxt/tree/ethink) have got some customization which makes it work with Ethereum accounts and signing, as well as to speak with _ethink!_ node in the same language (for that chain metadata was updated). > Worth mentioning here, as “_ethink!_” name could be a little confusing, that this solution is not solely for ink! contracts. > It is basically language-agnostic, and low coupled with the executor (meaning it should work both with Wasm and RISC-V -flavored pallet-contracts, and could be adopted to other embedders\executors if someday we will have new options for that). Still the most mature contracts language in our ecosystem is ink!, and it’s basically the only feasible one for production use so far. That’s why the project naming was made with an accent on it. ## Current State The [Prototype](https://github.com/agryaznov/ethink) includes a Substrate node with _pallet-contracts_ aboard and exposed Ethereum RPC. You can write your contracts in _ink!_, build them and deploy to the node using the fork of _cargo-contract_ tool. Then you can interact with the contracts via _Metamask_. Follow the guidelines written in the project [README](https://github.com/agryaznov/ethink/blob/0a93e8ee4e81a0380eecceb5626c557ea9282ccf/README.md) file to try it out. _ink!_ contracts have to use custom environment with 20-bytes-long account addresses, see the [example](https://github.com/agryaznov/ethink/blob/c600bbf759396b718cfb1edbbdf04ae6939e8b4e/dapp/contracts/erc20.ink/lib.rs#L3) contract on how to do that. Currently, there are two working examples, _Flipper_ and _ERC20_, with more to be added in the near future. There is also a little end-to-end testing framework, and the examples are covered with [integration tests](https://github.com/agryaznov/ethink/tree/c600bbf759396b718cfb1edbbdf04ae6939e8b4e/template/node/tests). Having a look at them might help to understand how input data is expected to be encoded on the caller side, and shed some light on the overall workflow of communicating with the node. Please feel free to play with the prototype, and give your feedback here to the comments, or to the project repository issues. ## What’s Next The possible next steps are (if you have better ideas, please tell so in the comments): 1. Update dependencies to recent _polkadot-sdk_. 2. Update examples to _ink! v5_. 3. Deploy this prototype to a testnet. 4. Choose a good Ethereum dapp and try to port it to the testnet. ## Shy Request to Community I would like to ask the community to propose some candidate dapps for migration from Ethereum to Polkadot, which would be simple enough to start with, and popular enough at the same time to make it the right target. We will take one and try to port it to a parachain with _ethink!_ aboard. I would also kindly ask for feedback from Polkadot core developers on the prototype introduced hereby, as I know this problem is being thought about for a while, yet I’m not aware of any other attempts of implementing this. Many thanks for reading all through to the end of this post =). ---
**Author:** ![alejandro](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alejandro/32/55_2.png) [@alejandro](https://forum.polkadot.network/u/alejandro)\ **Post date:** [April 11, 2024, 9:38pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/2 "2024-04-11T21:38:30Z")
Thanks for the update @sasha, this is fantastic! ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [April 12, 2024, 3:48am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/3 "2024-04-12T03:48:32Z")
Just one thing to keep in mind so such work can be compatible with light clients, Chopsticks, and the upcoming omni node: It needs to be built with a clear isolation with the node itself and ideally only communicate with the node via standard RPC. In that way, we can replace the node with a light client or Chopsticks and enjoy all the benefits. Otherwise you will end up with the same situation as Frontier that it wont’ work with Chopsticks or light clients. Let’s build modular and compostable software together. Also while I won’t have time to try to build some PoC, I suspect someone can reuse 95% of the code at [bodhi.js/packages/eth-rpc-adapter at master · AcalaNetwork/bodhi.js · GitHub](https://github.com/AcalaNetwork/bodhi.js/tree/master/packages/eth-rpc-adapter) and have a working solution done in less than a week ---
**Author:** ![sasha](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sasha/32/4694_2.png) [@sasha](https://forum.polkadot.network/u/sasha)\ **Post date:** [April 12, 2024, 1:12pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/4 "2024-04-12T13:12:25Z")
> [@xlc](#): > > It needs to be built with a clear isolation with the node itself and ideally only communicate with the node via standard RPC. In that way, we can replace the node with a light client or Chopsticks and enjoy all the benefits. Good point, thanks Bryan! Just checked, so far it looks like to be the case. > [@xlc](#): > > Also while I won’t have time to try to build some PoC, I suspect someone can reuse 95% of the code at [bodhi.js/packages/eth-rpc-adapter at master · AcalaNetwork/bodhi.js · GitHub](https://github.com/AcalaNetwork/bodhi.js/tree/master/packages/eth-rpc-adapter) and have a working solution done in less than a week So the idea is that with a custom fork of that `eth-rpc-adapter` (re-implementing the same logic of passing Ethereum RPC requests into runtime API calls as in `ethink-rpc` crate), one could use Chopsticks with it to enjoy a lightweight replica of any ethink-powered parachain, right? ---
**Author:** ![Cyrill](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/cyrill/32/7339_2.png) [@Cyrill](https://forum.polkadot.network/u/Cyrill)\ **Post date:** [April 12, 2024, 6:35pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/5 "2024-04-12T18:35:18Z")
Good stuff, we definitively want to have full compatibility, including ETH RPC and compatibility layers 🙂 For the runtime, contract languages should be fully opaque. I think that `ink!` would benefit from having contracts to optionally support Solidity ABI encoding too. An obvious example that comes to my mind for `ethink!` would be some ERC20 implemented in `ink!` but it looks like an actual ERC20 to users. W.R.T. to Solidity: Solang at the moment only supports SCALE (Solidity ABI could be implemented though if people are strongly interested in it); re-compiled YUL/EVM contracts on the other hand obviously will only support native Solidity ABI. Actually we might think about having some way to be able to distinguish between contracts using SCALE encoding, it might come beneficial once people start deploying contracts written in either Rust or Solidity that require different ABI encodings. A non-invasive way (not bothering the runtime at all) would be to just agree to an (optional) interface that contracts can implement, so they can be queried against their supported encodings. Or by storing a flag for each contract (basically when deploying a contract you’d specify what encodings it supports) and making this information available via a runtime API. Concerning `ink!` again, in theory we could have `ink!` contracts that support both encodings, i.e. they are callable from other `ink!` contracts using SCALE or as well Solidity contracts using Solidity ABI. ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [April 14, 2024, 2:13am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/6 "2024-04-14T02:13:20Z")
> [@sasha](#): > > So the idea is that with a custom fork of that `eth-rpc-adapter` (re-implementing the same logic of passing Ethereum RPC requests into runtime API calls as in `ethink-rpc` crate), one could use Chopsticks with it to enjoy a lightweight replica of any ethink-powered parachain, right? Yes. eth-rpc-adapter only uses a few runtime API to communicate with Acala runtime so it should be easy to just replace it with corresponding ink! runtime API and it should work. Then update the subql project to support pallet-contracts and the historical API should also work. Feel free to open issue on the repo if you want to give it a go and have more technical questions. ---
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [April 16, 2024, 10:45am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/7 "2024-04-16T10:45:55Z")
Thanks @sasha. Great work. > [@xlc](#): > > It needs to be built with a clear isolation with the node itself and ideally only communicate with the node via standard RPC. In that way, we can replace the node with a light client or Chopsticks and enjoy all the benefits. Do you mean host functions here instead of “RPC”? I can’t quite follow otherwise. Can you elaborate a bit more what the problem is in this regard with frontier? Does it expect the node to implement additional host functions? ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [April 16, 2024, 11:34am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/8 "2024-04-16T11:34:55Z")
I mean RPC. Frontier is part of the node and that’s the problem. ---
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [April 16, 2024, 1:32pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/9 "2024-04-16T13:32:16Z")
Okay got think. We don‘t get away with zero code in the client, right? You are suggesting to have a minimal forwarder and do most of the processing in the runtime? ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [April 17, 2024, 5:19am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/10 "2024-04-17T05:19:54Z")
I don’t think you get it. I mean having all the ETH RPC logic on a separate binary, which communicate with the Substrate node via Substrate RPC. The Substrate node is just a node implements Substrate RPC. e.g. the Omni node or Chopsticks. The ETH RPC binary will forward some work to be processed by runtime but it also handles a lot of the RPC process such as historical transaction. ---
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [May 3, 2024, 9:52am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/11 "2024-05-03T09:52:21Z")
You are right. I didn’t get it so far. Now it makes sense to me. As a separate binary we wouldn’t need to add support to each existing node. However, do you think this is feasible? For example our `submit_extrinsic` won’t understand an Ethereum transaction. This means the extra binary would need to somehow create a new transaction. How would this binary sign this transaction? Or do I have the wrong idea here? ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [May 4, 2024, 11:35am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/12 "2024-05-04T11:35:24Z")
It is already working for Acala so it is 100% feasible. There are few ways to deal with the tx format. Substrate is super generic so you can make it accept eth tx format and the RPC should just take it. For Acala EVM+, the eth-rpc-adapter repackage the eth tx format to Substrate format, and during tx verification, we reassemble the eth tx payload in the runtime for signature verification. ---
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [May 4, 2024, 11:51am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/13 "2024-05-04T11:51:49Z")
Thanks for explaining. I wasn’t aware how much of the transaction is opaque to the node. Yes, this sounds like the ideal solution. Not adding another burden for node implementors. ---
**Author:** ![pgherveou](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/pgherveou/32/1416_2.png) [@pgherveou](https://forum.polkadot.network/u/pgherveou)\ **Post date:** [June 3, 2024, 8:18pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/14 "2024-06-03T20:18:31Z")
Hey @sasha , thanks for the great post, this is critical for us to get these features, and we are happy to assist in any way we can. > [@sasha](#): > > Good point, thanks Bryan! Just checked, so far it looks like to be the case. Looking at the code, It looks like that as it is right now, ethink Eth RPC server, is tied to the node as it is using the shared Runtime client, instead of communicating with the node through RPC. > [@xlc](#): > > It needs to be built with a clear isolation with the node itself and ideally only communicate with the node via standard RPC. In that way, we can replace the node with a light client or Chopsticks and enjoy all the benefits. @xlc you mean that this design is superior as you can point the proxy to any kind of Substrate node (e.g lightclient or Chopsticks) or just embed it into a client library. ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [June 4, 2024, 9:42am UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/15 "2024-06-04T09:42:58Z")
> [@pgherveou](#): > > you mean that this design is superior as you can point the proxy to any kind of Substrate node exactly. here is an example [bodhi.js/examples/chopsticks at master · AcalaNetwork/bodhi.js · GitHub](https://github.com/AcalaNetwork/bodhi.js/tree/master/examples/chopsticks) ---
**Author:** ![sasha](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sasha/32/4694_2.png) [@sasha](https://forum.polkadot.network/u/sasha)\ **Post date:** [June 7, 2024, 2:14pm UTC](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375/16 "2024-06-07T14:14:22Z")
> [@pgherveou](#): > > Looking at the code, It looks like that as it is right now, ethink Eth RPC server, is tied to the node as it is using the shared Runtime client, instead of communicating with the node through RPC. In current version yes, it’s tied to the node. I just meant that what Bryan suggests seems doable to me (apologizes for vague wording in that reply), and I plan to do that on a further stage.