So you are considering deploying your contract, but you don't want to pay the high fees that Ethereum right now has? These two off-chain scaling solutions for Ethereum might be interesting for you.
Layer 2 is a construction that runs on top of The Ethereum mainnet. The main objective of L2 is to move the state computation power off-chain, and anchor the new states back to the mainnet or L1. Because the new states will be validated by the consensus protocol of the mainnet, the security of the Layer 2 is inherited from the L1.
On the other hand, sidechains, are also considered a Layer 2 scaling solution. However, they are independent blockchains. They are Ethereum compatible and have their own consensus mechanism/their own security.
So, it can be said, that the more significant difference between L2 and Sidechains (besides all the technical/implementation aspects) is the consensus mechanism/security→ decentralization.
Let's check two examples:
Layer 2: Arbitrum network (uses Optimistic Rollups).
In Optimistic Rollups, there are two main roles/parties/nodes: The Aggregator, who computes (off-chain) the new states of users, wraps all the computed states/transactions, and sends them to the on-chain smart contract.The Challenger, who, during a fixed period, will verify and compute the submitted states of Aggregators.
Brief workflow:
Aggregator makes a deposit in order to become an Aggregator.
Users connect to Aggregators and send transactions.
Aggregators compute new states, wrap them and send them to the on-chain smart contract.
Validators verify the Aggregator's submissions. During this time the Agegator can not submit new batches of transactions.
If something is wrong with the submitted transactions, Validators will submit a fraud-proof to the rollup smart contract, the contract will verify the proof and revert the batch if needed.
If there is no a fraud-proof, submitted transactions are considered valid.
After the fraud-proof time, Aggregators can start to submit new batches of transactions.
Sidechain: Polygon PoS
Polygon is an Ethereum-compatible blockchain, which uses Proof of Stake to validate the new states of the polygon blockchain. However Polygon is not just a sidechain, the Polygon ecosystem is growing every day and also offers an L2 that uses zk-rollups.
Developers can deploy their Ethereum Dapps on these scaling solutions with just a few adjustments in their deployment process.
*** Depending on the needs that an application should have, a developer can choose between these scaling solutions. As mentioned, security and decentralization is the main difference between L2 and sidechains. Hence if the applications “need” the decentralization and security that Ethereum mainnet has, a L2 like arbitrum would be a “better” option. ***
That said, let's deploy the “Owner.sol” contract from the Remix-Ethereum Project in the Arbitrum network (testnet)
Requirements:
→ First, let's create an empty brownie project using our terminal: brownie init
→ Now we can copy the “Owner.sol” contract into our Contracts Folder.
→ We also need a node to deploy our contract. Alchemy helps us with this. Creating an account is really easy, just log in with your Google account and you are set to go:
Click on CREATE APP, select chain and network, and create the App.
Once the App is created, we can access the connection information by clicking the VIEW KEY button. This information should be kept secure and not shared.
→ Add the Api Key to the .env file in the project:
export WEB3_ALCHEMY_PROJECT_ID= 'API KEY'
→ Brownie does not have by default the Arbitrum rinkeby testnet, checkbrownie networks list, let's add it using our Alchemy Api Key and the network info. We can add a new network to brownie with the brownie networks add command. However, we can also create a .yaml config file to add new networks to brownie:
live:
- name: Arbitrum
networks:
- chainid: 421611
explorer: https://testnet.arbiscan.io/
host: https://arb-rinkeby.g.alchemy.com/v2/$WEB3_ALCHEMY_PROJECT_ID
id: arbitrum-rinkeby
multicall2: '0x5BA1e12693Dc8F9c48aAD8770482f4739bEeD696'
name: Rinkeby (alchemy)
we also need the brownie-config.yaml with at least the .env info in order to use the env variables
dotenv: .env
And now load the network config with brownie networks import ./my-network-config.yaml
→ Now let’s add our deployer account to brownie, but first, let’s configure metamask to work with arbitrum rinkeby. Visit chainlist, search for arbitrum rinkeby and add the network to metamask.
In order to keep your private key safe, you can use brownie accounts new <my_account> to add your account, and then with accounts.load('my_account'), use the account to deploy your contract. With this method, we don't have to expose the private key in the .env file.
→ Now we need test eth to deploy our contract, we can get rinkeby eth here, and then bridge it to arbitrum rinkeby testnet. With enough eth in our wallet we can run our deploy script:
from brownie import accounts, Owner
def deploy():
account = accounts.load("my_account")
contract = Owner.deploy({"from":account})
print(f"contract is: {contract}")
owner_account = contract.getOwner()
print(f"owner is: {owner_account}")
def main():
deploy()
brownie run scripts/deploy.py --network arbitrum-rinkeby
Our contract should be now deployed to the arbitrum rinkeby testnet : )
References:
→ https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/