A blockchain is a distributed and decentralised database that allows everybody to transparently verify that what we write there cannot be changed illegitimately in any way. So this technology is perfect to memorise contracts, ownership acts, financial operations without the need of a human notary or a bank, in a way that is completely decentralised and makes impossible for anyone to cheat.
The big limit of this technology is that is quite slow and expensive. In fact, a transaction could require minutes and some dollars to be executed by the system. This is not a critical limit for big exchanges, for example real estate related ones, but is not acceptable if you require a big number of small transactions, because in that case the price to pay to use the safety of the blockchain is probably bigger than the transaction itself.
What we would want is to benefit of the extremely high security of Ethereum, but in a more fast way.
In this article we want to analyse Polygon, a possible solution that could tackle this problem for Ethereum, in a use case that needs lots of fast and low-priced transactions.
The possible solution: Polygon
Polygon is a sidechain of Ethereum, it means that is a separated blockchain, similar to the parent one, able to easily communicate with the Ethereum one.
So we can put our contract to Polygon, keep our coins or nfts there, and periodically Polygon is going to report its transactions on Ethereum.
Polygon from a programmer point of view is almost identical to Ethereum: you can still write contracts in Solidity, deploy them with Truffle, interact with them using Web3Js, so Polygon can easily fit any Ethereum based ecosystem. So how polygon is different from Ethereum? Polygon is quick and inexpensive (thousands of times faster and cheaper than Ethereum). This is possible because there are a few differences:
Proof of stake vs proof of work
Ethereum uses the proof of work to validate the transactions, Polygon the proof of stake. Both are consensus mechanisms, but they are different:
– in Proof Of Work (POW) validation of transactions is done through mining: it is a competitive process when different users try to validate (“mine”) a block of transactions, and the first one who can do it is rewarded with some coins. The validation itself, based on hash, is trivial for a modern computer, so in order to make it a “work” the system has ways to make the process expensive. So the act of mining requires a lot of computational power, that’s why is extremely safe but slow, and less environmental friendly.
– in Proof Of Stake (POS) validation is not competitive, the system select some users to validate blocks through some rules related to the “stake” they have on the blockchain. The stake in this context is the amount of coins they are ready to commit to have the opportunity to being selected as validator. In this system there is no need to make the validation a “work”, so it is a very economical and fast process.
Can we affirm that Polygon, using the proof of stake is as safe as Ethereum? Well there are different opinions about comparing safeness of POW and POS, but Polygon periodically write some information on Ethereum about its transactions, so there is a “double check” that guarantee that is arduous to manipulate information.
Polygon checkpoints on Ethereum
Polygon is a sidechain so periodically have to write some “checkpoints” (that are information about transactions) on the main chain, in this case Ethereum, in order to benefit from the extreme Ethereum safety . Polygon doesn’t write the whole information, because it would be costly, but just an hash, obtained taking the root hash of a Merkle Tree where the leaf nodes are the transactions itself. So if there is even a minor change in the transactions in Polygon the root hash is going the be very different and everyone can notice it comparing with the checkpoint on Ethereum.
From a developer point of view the tools needed to create smart contracts in Polygon and interact with them are the same used for Ethereum:
– We write the contracts using Solidity, that is a simple object-oriented language highly specialised for smart contracts implementation. Despite not having the amount of libraries and functionalities or the advanced dependency management systems that we could expect from Java or Python it is enough to do strictly what is needed in its domain. Note that Solidity and most of its documentation are created with Ethereum in mind, so they are stressed to work in a system where each computation is overpriced, but under this point of view Polygon is very affordable and we can optimize less this aspect.
In this case is important to stress particularly on the importance of testing: when the contract is deployed in production it is a very complex matter to update it keeping the data. The entire point of a blockchain is to keep the contract immutable so is critical to be sure to deploy it only when is bug-free.
– When we are ready to deploy the contract in an external environment we can use Mumbai, who is the free Polygon testnet. There we can verify again that everything works as expected
– Exactly as for Ethereum we can interact with our contract using Web3Js, we don’t need to change anything here. Also there are porting of this library for Java and other languages.
How to provide a Polygon node
You could actually consider to run your node on a physical machine or on an AWS EC2 node, but it is quite high-cost (the node itself needs a very powerful machine). The most pragmatical solution is probably to use one of the numerous node providers like Infura, Geth, Quicknode etc so pay a third-party to provide you and endpoint where you can execute web3js calls. It’s important to note that these providers comes with the nodes, but you still have to provide the coins needed to pay the gas.
If you want to enjoy the safeness of Ethereum but executing fast and inexpensive transactions Polygon can be an easy solution, able to allow the developer to re-use their existing knowledge of Ethereum tools