Layer 2 Network
Funganomics has already planned, designed and researched ready to build its own Layer 2 solution, which will provide us with the ability to scale our own ecosystem.
We can manage security from within our ecosystem as technology develops, it's important that our products and infrastructure stay ahead of the sector.
Bridge securely with networks we see as value to expansion and benefit our growth.
We can manage congestion problems by creating a multi chain system across multiple blocks.
Vet and approve projects that add value to our ecosystem with a quality over quantity approach.
Create a multi ecosystem gas fee protocol that balances commercial and private user needs.
A separate Whitepaper will be provided to explain our network in more detail, with a key focus on technical specifications and use case.
Research thesis documentation
The details below show our research, this is merely to show an overview of data on which we can validate and create our Layer 2 solution. What we already know is need a custom solution based on our findings above.
Layer 2 Solutions
Abritrum
Rollups -> Executing tx. outside layer1 and posting tx data on layer1.
Optimistic rollups (EVM compatible optimistic rollup solutions)
A separate manager contract is used to replay the transaction on layer1 to detect fraud tx. * Hopp protocol and connext reduce the withdrawal time from layer1. * Optimism and Arbitrum widely used optimistic rollups.
Arbitrum -> The three primary components of Arbitrum include validators, compiler, and the EthBridge.
The Compiler helps in the compilation of an assortment of solidity smart contracts into executable files compatible with running on AVM or the Arbitrary Virtual Machine. The validators are primarily responsible for the majority of the off-chain Work alongside monitoring the state of the AVM. EthBridge is basically a decentralized application, which is deployed on the ethereum main network. It serves as a connection between the Ethereum main network and arbitrum.
Zk rollups
It uses validity proofs
Advantages of ZK over OR ZKRs have short finality/exit times (minutes vs. days in ORs). ZKRs are cheaper (addresses, signatures and intermediate state hashes can be omitted). ZKRs are A LOT more secure with large value locked in them
Starknet protocol
StarkNet is a permissionless decentralized ZK-Rollup. It operates as an L2 network over Ethereum, enabling any dApp to achieve unlimited scale for its computation – without compromising Ethereum's composability and security. Smart contracts are written in Cairo
Withdraw is used to withdraw native ERC20 tokens to L1. Please note that this type most likely will be removed after the testnet. Execute is used to call smart contract functions. Deploy is used to deploy smart contracts on zkSync. There are also two types of transactions, related to bridging native tokens to zkSync: Deposit is used to move funds from an L1 account to an L2 account. AddToken is used to register a native ERC20 token to zkSync.
Current Limitations
Support for native ETH transfers by passing a value field to the transaction is not supported yet. As a consequence, msg.value is always equal to 0 Unsupported opcodes
block.gaslimit always returns 2^32-1. EXTCODESIZE always returns 0xffff. MSIZE always returns 2^16. At this time zkSync is solely run and operated by the zkSync team's servers, and is therefore centralized;
Optimism
Optimism is a Layer 2 scaling solution for Ethereum that can support all of Ethereum’s Dapps. Instead of running all computation and data on the Ethereum network, Optimism puts all transaction data on-chain and runs computation off-chain, increasing Ethereum’s transactions per second and decreasing transaction fees
Sequencers on Optimism are responsible for executing computation off-chain and publishing compressed transaction data onto a smart contract on Ethereum at regular checkpoints.
How Blocks are stored
All Optimism blocks are stored within a special smart contract on Ethereum called the CanonicalTransactionChain. Optimism blocks are held within an append-only list inside of the CTC. This append-only list forms the Optimism blockchain.
How Blocks are Produced
Optimism block production is primarily managed by a single party, called the "sequencer". The sequencer applies some basic compression techniques to minimize the amount of data published to Ethereum.
Block execution
Optimism nodes download blocks directly from the append-only list of blocks held within the CanonicalTransactionChain contract. Optimism nodes are made up of two primary components:- Ethereum data indexer also called data Transport layer Optimism client software (l2geth)
Smart Contracts used in Optimism
Chain Contracts It is deployed on ethereum mainnet The chain is composed of the following concrete contracts:
CanonicalTransactionChain (CTC) The Canonical Transaction Chain (CTC) contract is an append-only log of transactions which must be applied to the OVM state. The CTC also allows any account to enqueue() an L2 transaction, which the Sequencer must eventually append to the rollup state.
Contract ->
https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L1/rollup/CanonicalTransactionChain.sol
State Commitment Chain (SCC) The State Commitment Chain (SCC) contract contains a list of proposed state roots which Proposers assert to be a result of each transaction in the Canonical Transaction Chain (CTC).
Contract ->
https://github.com/ethereumoptimism/optimism/blob/master/packages/contracts/contracts/L1/rollup/StateCommitmentChain.sol
ChainStorageContainer Provides reusable storage in the form of a "Ring Buffer" data structure, which will overwrite storage slots that are no longer needed. There are three Chain Storage Containers deployed, two are controlled by the CTC, one by the SCC.
Contract ->
https://github.com/ethereumoptimism/optimism/blob/master/packages/contracts/contracts/L1/rollup/ChainStorageContainer.sol
Verification
It checks the validity of transactions data
BondManager
The Bond Manager contract handles deposits in the form of an ERC20 token from bonded Proposers. In the event of a successful challenge, the faulty Proposer's bond is slashed, and the Verifier's gas costs are refunded. Contract -> https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L1/verification/BondManager.sol
BridgeContracts The Bridge contracts implement the functionality required to pass messages between Layer1 and layer2.
L1CrossDomainMessenger The L1 Cross Domain Messenger (L1xDM) contract sends messages from L1 to L2, and relays messages from L2 to L1. Contract -> https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol
L2CrossDomainMessenger The L2 Cross Domain Messenger (L2xDM) contract sends messages from L2 to L1, and is the entry point for L2 messages sent via the L1 Cross Domain Messenger. Contract -> https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L2/messaging/L2CrossDomainMessenger.sol
Avalanche
Avalanche features 3 built-in blockchains: Exchange Chain (X-Chain), Platform Chain (P-Chain), and Contract Chain (C-Chain). All 3 blockchains are validated and secured by the Primary Network.
X-Chain It uses Avalanche Consensus Protocol Used for assets creation, assets exchange
C-Chain It uses Snowman consensus protocol. Specific for Ethereum Smart Contracts.
P-Chain (Platform Chain)
It is specifically for management of subnets, also coordinating all the validator nodes, and also the staking mechanism.
What are subnets? Each subnet is a new network in the avalanche ecosystem. Each subnet can have a multiple blockchains just like the primary avalanche network Each blockchain in a subnet can have its own consensus mode (i,e. Proof of work, proof of stake). Each blockchain can have its own VM. They can be permissionless or permissioned. Change the rules for each blockchain.
Snowman Protocol Snowman protocol has been optimized for smart contracts and high throughput
Create Custom Blockchain using Avalanche P-Chain
Prerequisites We will need a running node, a user on the node, and some AVAX in the address controlled by the user. And we need to have our node be a validator on the Primary network.
Avalanche supports the creation of new instances of the Ethereum Virtual Machine.
Avalanche Provides these VMs:- Subnet-VM AVM TimeStampVM
Run an avalanche node
Requirements: CPU: Equivalent of 8 AWS vCPU RAM: 16 GiB Storage: 512 GiB OS: Ubuntu 18.04/20.04 or MacOS >= Catalina
Steps to bootstrap the node Build binary or download pre-built binary. Start node Create a keystore user Create an address
Run a Five Node Network with Avash Avash is a development network for running a test or private Avalanche network on your local machine.
Dependencies Golang -> v1.17 AvalancheGo -> Must have the latest version of avalancheGo installed Avash -> Installed latest version of avash
Start the Network Run five-node-staking.lua script to bootstrap the nodes. It fires up a local Avalanche network with 5 full AvalancheGo Nodes. You can interact with each individual node over RPC. Inspect the Network -> Avash's shell provides the procmanager command which enables you to list, stop, and start processes registered with the process manager.
Run a Five Node Network with Avalanche Network Runner The Avalanche Network Runner allows a user to define, create and interact with a network of Avalanche nodes. It can be used for development and testing.
Steps: Define the network Start the network Interact with it Shutdown
Last updated