Ethereum Solidity vs RSK RSKScript: Smart Contract Development
In 2016, the RSK project began as a fork of the Ethereum codebase, and it underwent two years of development until its official introduction in 2018. Precompiled contracts, new opcodes, and important data structures were added or upgraded during those years. As the RSK community has always prioritized Ethereum compatibility, the majority of changes remain undetectable to users and developers. RSK and Ethereum are viewed by developers as twin brothers.
Next, RSK use language similar to Ethereum to ensure user interface consistency; the primary distinction is the unit of account, which is BTC instead than Ether. Because of these similarities, several wallets, like Defiant and Beexo, support both RSK and Ethereum. The only UI tweaks wallet developers need to do to enable the BTC ticker are minimal ones. On RSK, common notions like gas, smart wallets, and ERC-20 tokens are also present.
By adopting an address structure that resembles Ethereum’s, RSK further improves user interface compatibility while preventing Ethereum addresses from being inadvertently utilized in the context of RSK smart contracts and vice versa. But in Latam, the RSK ecosystem has developed to such an extent that wallets like Defiant began supporting RSK before thinking about supporting Ethereum. Conversely, some well-known wallets, like Metamask, make it necessary for the user to explicitly set up RSK as a special network in order for it to function as an RSK wallet, which negatively affects the user experience.
Supporting standard JSON-RPC commands, often known as web3, is necessary for infrastructure services to be compatible with the Ethereum network. Wallets and developers need these commands to issue, broadcast, communicate, and confirm transactions with RSK nodes. Regarding this, RSK and Ethereum are sufficiently compatible to support the majority of common tools. There are a lot of infrequently used debug techniques in Geth and Parity that are not supported by RSK nodes.
Network node compatibility is the following category. After Ethereum 2.0 is available, the Ethereum 1.0 network layer will not be updated or supported as Ethereum is giving up on the Eth 1.0 network standard. Being compatible with an abandoned project is pointless. Furthermore, it won’t be simple to create a new RSK full node in 2020 by transferring an already-existing Ethereum node, as many fundamental data structures have been enhanced.
For instance, the block headers for RSK and Ethereum are different in a few aspects, and RSK features more non-trivial precompiled contracts. It is still possible to create network tools that support both networks.For instance, modifying the user interface to display the updated header information is all that is needed to add RSK functionality to an Ethereum block explorer.
Lastly, the RSK community has not previously demonstrated a desire to provide execution costs comparable to gas. The inherited gas prices would never match the real resource use of an RSK node, not even if someone tried. This is due to the fact that the RSK node is tuned differently than an Ethereum node; for example, certain operations (such EXTCODESIZE) that are extremely slow on an Ethereum node are extremely quick in RSK.
RSK is heading toward a storage cell-level model that includes access and storage fees. With this version, the node will be more resilient to unanticipated DoS assaults involving resources. Consequently, RSK won’t require the ongoing repricing of I/O opcodes that the Ethereum community carries out on each net hard fork.
