Qtum uses the Ethereum Virtual Machine (EVM) to allow smart contracts on our blockchain. Because Qtum is a fork of Bitcoin, it belongs to the “Unspent Transaction Output” (UTXO) family of projects. The reasoning for this is vast and could make for a long article. The ability to leverage upstream development work allows Qtum to adapt fast. For example, Qtum can integrate Bitcoin’s new Taproot functionality instead of engineering a native version from scratch. This also means more backward compatibility, security, and decentralization.
Let’s get back to the topic of smart contracts. Developers can port their Ethereum Decentralized Applications (DApps) or build them natively on Qtum. This is accomplished through the “Abstract Account Layer” (AAL), a middleware layer between the EVM and Qtum. This is fine for copy/pasting contracts, like a Uniswap liquidity pool or an airdrop script. However, what happens when you are trying to build an ecosystem like SushiSwap that makes use of oracles and so forth? Then you need an entire sandbox environment that effectively mimics Ethereum call by call.
Qtum’s implementation of Janus will achieve this, allowing developers to access an environment that imitates Ethereum while providing some Qtum quirkiness. People may ask what’s the point, why not just build on Ethereum? The typical responses about high gas fees and slow transactions are valid, but we plan to take this up further. Because of Qtum’s hybrid nature, the best parts of Bitcoin and other UTXO blockchains will be available in a native environment. This means having access to Bitcoin’s Taproot, alongside the new “evmone,” virtual machine, which combined are very powerful. No other blockchain can offer this amplified combination. It may even be possible to apply this functionality for compatibility with Solana, NEAR, and Cosmos. We’ll cover this in the next section.
Janus was created to adapt the RPC (Remote Procedure Calls) layer of Qtum to run Ethereum style commands. For the time, Qtum had been using Bitcoin’s RPC command library and used a couple of custom-made calls that, while simpler, are just not compliant with Ethereum, which is where much of DeFi and NFT applications have been written for. In addition, writing in Go rather than C++ can also be a little quicker in exposing various functions that emphasize the unique strengths and parallels of the UTXO model that might more neatly potentially be exposed via native namespaces (qtum_OpSenderGasRelay, qtum_batchEthTransactions, qtum_executeEVMInParallel, qtum_rentUTXOState, etc.).
The difference between Qtum and Ethereum is the account model. Qtum is based on UTXOs and has an account abstraction layer (AAL) to do the mapping internally. Still, transaction signing is fundamentally different and needs to be accounted for when migrating apps.
To get around this problem, Qtum has decided to make Janus — an adapter that will map various RPC commands directly into a language that Qtum can easily translate. The adapter takes in an RPC request in ETH format, relays the appropriate request to Qtum, and returns a translated response to the user interacting with Qtum as though it were a web3 provider. This also gives a bonus of making a layer that can communicate and translate the native platforms among many blockchain solutions such as Solana, NEAR, and Cosmos.
Janus implements the Ethereum JSON RPC and uses the same API to query and extract information from the blockchain. Since Qtum already supports smart contracts, the developers will need to just deploy contracts and point their apps at the deployed contracts and Janus.
Since Janus is server software, it can’t hold users’ private keys, so transaction signing needs to happen on the client. It is intended to act like geth in that regard, you can import your private keys to Janus/qtumd (the Qtum daemon node/wallet) and point your apps at it and let Janus/qtumd sign your transactions, and it will work — but it’s a huge barrier to entry, which is why MetaMask has come along to do signing on the client. Janus also has implemented transaction signing as an ethers-js module.
Janus has also implemented transaction signing as an ethers-js module. For example, “qtum-ethers” is a popular web3 library that allows any application using the “ethers” library to be ported with relative ease. Click here to see how it works.
How can developers utilize the ethers-js module on Qtum? For that, they will need to use Qtum’s MetaMask fork named “Qnekt”. The only difference between apps using Ethereum MetaMask and Qtum Qnekt will be how the app initializes things.
Developers will need to reference window.qtum instead of window.ethereum to interact with our browser extension. The reason this is done is to reduce confusion with wallet interaction. Solana MetaMask also does this same thing.
Creating a programmable blockchain while staying true to the original UTXO model was something that Qtum planned to do from the very beginning. With Janus implementation, Qtum will empower developers to migrate the rich ecosystem they have created on top of Ethereum to Qtum. To understand why this is so valuable, check this.
The snapshot above shows you the total value locked (TVL) in Ethereum’s decentralized finance (DeFi) ecosystem. Yes, you read that correct — $169 billion! More importantly, note that this number is less than a billion dollars before 2020. This is because DeFi has exploded exponentially over the last two years.
The Janus wrapper will empower developers to easily port these apps over to Qtum and benefit significantly from reduced gas fees.
There is another interesting thing that we need you to look at. As per DappRadar, these are the top 10 Ethereum-based applications, by users over 24 hours.
The top 10 apps have had >85,000 active users in 24 hours (late November). In other words, not only will Janus allow developers to port over their apps, but they will inevitably port over a significant portion of their existing user base. This will be very valuable to the long-term growth potential of Qtum.
Why? Consider Metcalfe’s law. The law states that the “value of a telecommunications network is proportional to the square of the number of connected users of the system.” To visualize this, consider the following diagram.
- Two telephones can make only one connection.
- Five can make 10 connections.
- Twelve can make 66 connections.
As you can see, the correlation between users and actual utility is direct and exponential. Therefore, we believe that Janus will help kick up Qtum network’s utility exponentially as per Metcalfe’s Law.
The future of the crypto ecosystem lies in establishing proper interoperability. Janus will allow Qtum to synch easily with Ethereum’s ecosystem and empower developers to create multi-chain applications.
GitHub Qtumproject Janus https://github.com/qtumproject/janus