Frequently Asked Questions
What's the Coinweb story?
Coinweb was founded in 2017 with a vision to revolutionise the crypto space by creating a multi-chain wallet that provided the unique ability to generate human-readable wallet addresses across multiple blockchain networks. This innovative approach would allow users to use and transact with a single address, like "JohnDoe.cweb," seamlessly on various chains. Whilst building this, our team identified the potential to develop a payment platform utilising the wallet's functionality alongside a bespoke broadcaster.
In December 2020, two payment platforms were successfully launched, utilising working components of the Coinweb platform, marking a significant milestone for the company. During the first year these payment platforms issued and sold stable tokens through the Coinweb platform for more than $90m. Recognising the immense potential of our technology’s full capabilities, we published an extensive new whitepaper in May 2021, outlining our vision for expanding and enhancing our offerings in the blockchain industry. As we continue to push the boundaries of what's possible in the decentralised world, Coinweb remains committed to driving innovation and delivering cutting-edge solutions to their users.
How does Coinweb remain decentralised?
Coinweb's control over the protocol development does not extend to transaction consensus, which relies on the underlying blockchains. The level of decentralisation for individual transactions varies based on the specific blockchain in use, as Coinweb inherits the properties of the underlying chain.
Coinweb is undeniably a decentralised architecture. When operating on the Mainnet, anyone can run Coinweb, regardless of whether they choose to run it on AWS or in their own basement. The choice of deployment location does not affect its decentralised nature.
We have designed Coinweb in a way that requires fewer installations to ensure security. Even with just 10 nodes in a decentralised Coinweb setup, it offers the same level of security as a Layer 1 system with 1500 nodes.
This is made possible by the robust proof system implemented in the Coinweb client, which can effectively distinguish between honest and dishonest Coinweb nodes without blindly relying on a consensus system.
In the construction of a traditional Layer 1 system, a high degree of decentralisation is necessary due to constant decision-making regarding data inclusion in the blockchain. The goal is to prevent any single party from having the ability to censor data. Additionally, most Layer 1 systems rely on a single "root hash" to represent the outcome of smart contract execution, requiring a sufficient number of validators to verify the accuracy of computations.
In Coinweb, we have expanded the proof mechanism to allow Coinweb clients to determine whether they are receiving incorrect data or the correct result, as long as they can connect to a single honest Coinweb node in the network. This reduces the reliance on high decentralisation solely for trusting the root hash (Layer 1 computation).
Given the complexity of Coinweb, its deployment target is Kubernetes, a system for managing containerised workloads across a cluster of machines. Consequently, there may be fewer Coinweb installations compared to a traditional Layer 1 system. It is important to note that this does not compromise the decentralisation of Coinweb but rather enables more computational capacity at a reduced cost, as the total computing power in the network is not needlessly duplicated.
What consensus mechanism does Coinweb use?
Coinweb does not add its own consensus, the information in the underlying chains has already been voted on and it is not necessary for a second vote. Instead, we use a technique that proves the information in the different blockchains directly, without voting. By removing the additional consensus layer (blockchain) between the chains, we get rid of a lot of overhead and security problems.
How much does Coinweb scale?
Coinweb has implemented various techniques to minimise gas consumption per transaction, potentially reaching as low as 1,250 gas. These techniques involve user-defined signature schemes with signature aggregation, compression, ordinal or MTF encoding of addresses, and batching. These optimisations allow us to determine the maximum Transactions Per Second (TPS) achievable on EVMs.
Let's consider BNB as an example. BNB has a hard limit of 120,000,000 gas usage per block (y), and a new block is created every 3 seconds (z). By applying the formula (y/1250)/z, we find that Coinweb can achieve a maximum TPS of 32,000 on the BNB network. This is significantly higher than BNB's own maximum TPS of 2,200.
However, Coinweb's layer 2 solution is not limited to BNB alone. On the Ethereum network, Coinweb can achieve a maximum TPS of 2,000, while on Polygon (MATIC), it can reach 12,000 TPS.
By reducing the number of individual transactions processed on Layer 1 (L1), Coinweb effectively mitigates congestion and enhances network efficiency. As a result, transactions become faster and more cost-effective for users.
How much does Coinweb save on gas fees?
When you pay fees in a blockchain, you pay for different resources, but let's say storage and computation are the most important ones. Storage can be decomposed into multiple types of storage with different prices. On Bitcoin, there is utxo which is the most expensive storage, and segwit which is the cheapest. On Ethereum there's "storage" which is the most expensive, and calldata and logdata which is the cheapest.
Computation is also a resource you are paying for and this is decomposed into various types of instructions and/or script types based on the network.
What layer 2 systems do is they use the cheapest possible storage at layer 1, and avoid all computation costs at layer 1. You still end up paying for computation at layer 2, and even storage at layer 2.
For example, just storing data in a transaction costs 512 gas for 32 bytes, while storing the same in storage is 20000, a 20x difference which might increase further. Thus even if you need to pay for layer 1, there is plenty to do at layer 2 which will also require fees, and the total will easily be a lot less than what you would pay at layer 1 for the same amount of work.
To give a tangible example, below is the transaction cost for a general-purpose dApp using Coinweb’s batching of transactions. Some of these chains are yet to be connected to Coinweb. Please also remember that gas fees fluctuate and that cost per L1 tx may vary.
Is Coinweb Quantum Resistant?
- If a quantum attack on an underlying chain's consensus happens, then there can be a lot of reorganisations/slashing and general havoc. For Coinweb, when reorganisations increase, it means that the delay required to trust the data from shards that read from such a (broken) blockchain will have to increase (towards infinity), at which time it is unreachable for the rest of the coinweb shards. This means the shard(s) reading from the blockchain will sort-of will freeze until its consensus is sorted out, maybe forever, i.e. removal from the delay graph.
- For PoW blockchains like Bitcoin, even if the signature scheme is broken, the block building is actually quantum resistant as it is based on hashing. Bitcoin and similar will have to move to SHA2-512 which is a "trivial" change for block construction and merkelization. There is the potential for widespread spam on the chain, but the quantum attacks will (likely) focus on draining large wallets instead of saving $0.2 in fees. As long as block construction works, Coinweb will work.
- Coinweb itself is somewhat unique (?) in that it doesn't have any preferred signature mechanism. We currently use ECDSA which is not quantum resistant, but a User which is associated with holding a token amount is the combination of a signature-checking-smart-contract + raw bytes representing the pubkey. Thus in the tokenisation platform, for example, you can create a token where some tokens are protected by an ECDSA signature, another by a DAO, and a third by a quantum-resistant Lamport signature.
So all in all, Coinweb is not completely immune to the quantum computer armageddon, because the underlying blockchains are not, but we are almost as immune we can be while still embracing blockchains that are not quantum-resistant.
What are the USPs of Coinweb?
- Consensusless interoperability in L2 for unique consistent cross-chain operations
- Parallel execution layer on top of single chains and across multiple chains for unparalleled computational scaling
- Blockchain agnostic and distributed application layer allowing dApp traffic to be run on optimal combination of blockchains and enabling fail-safe mechanisms
- Unlimited transactional scaling across multiple blockchains
- Unique reactive smart contracts can monitor and react to L1 events on underlying blockchains giving full data availability and maximised value generation through autonomous onchain data aggregation, analytics and monetisation
- Massive cost savings and capacity increase by lowering L1 footprint with transaction batching and compression
- Frictionless user experience with true gas-fee abstraction for both L1 and L2 operations
Which chains does Coinweb currently support?
The L1 blockchains that Coinweb supports are the ones visible in the explorer. Adding additional Ethereum-like or Bitcion-like blockchains is straight forward.
Are Ethereum Layer-2 solutions like Optimism, Arbitrum, and other rollups considered "L1 blockchains" with their own Coinweb shards?
Yes, in the Coinweb documentation, all real L1 blockchains as well as L2 rollups are referred to as L1 blockchains to simplify the exposition in the documentation.
Do I need to buy or setup a node in order to develop on Coinweb?
No, there are public production nodes and devnet nodes available.
When using create-coinweb-dapp, your project is already setup to use https://api-devnet.coinweb.io/ which is a public devnet endpoint.
It is also possible to develop using the dev container which is a local environment that includes a devnet, explorer, and other tools.