Assess Avalanche integration

[guidiaz]

https://docs.avax.network/:

• Avalanche is the first decentralized smart contracts platform built for the scale of global finance, with near-instant transaction finality. Ethereum developers can quickly build on Avalanche as Solidity works out-of-the-box.
• AVAX is the native token of Avalanche. It’s a hard-capped, scarce asset that is used to pay for fees, secure the platform through staking, and provide a basic unit of account between the multiple subnets created on Avalanche. 1 nAVAX is equal to 0.000000001 AVAX.

[guidiaz]

https://support.avax.network/en/articles/4626956-how-do-i-set-up-metamask-on-avalanche

[guidiaz]

https://docs.avax.network/learn/platform-overview/

• 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. The Primary Network is a special subnet, and all members of all custom sunets must also be a member of the Primary Network by staking at least 2,000 AVAX.

[guidiaz]

Avalanche Blockchain Consensus:

• Avalanche is a new consensus protocol that is scalable, robust, and decentralized. It has low latency and high throughput. It is energy efficient and does not require special computer hardware. It performs well in adversarial conditions and is resilient to "51% attacks."
• Whitepapers: https://www.avalabs.org/whitepapers
• Video: https://youtu.be/ZUF9sIu-D_k

[guidiaz]

Launch Your Ethereum dApp on Avalanche:

• Avalanche is a network of networks. It means that is not a single chain running a single, uniform type of blocks. It contains multiple subnets, each running one of more heterogeneous chains.

• But, to run an Ethereum dapp on a low-fee, fast network with instant finality, all we need to know is that one of the chains running on Avalanche Primary Network is the C-Chain (contract chain).

• C-Chain runs a fork of go-ethereum called coreth, that has the networking and consensus portions replaced with Avalanche equivalents. What's left is the Ethereum VM, which runs Solidity smart contracts and manages data structures and blocks on the chain.

• There are multiple ways of working with the C-Chain:

  • Through MetaMask
  • Using the public API nodes
  • Running our own node
  • Running a local test network

• Developing and deploying contracts:

  • Remix, Hardhat and Truffle can be used to test and deploy smart contracts on Avalanche
  • Avalanche testnet faucet

• Avalanche's EVM main differences wrt/ Ethereum's EVM:

  • Measuring time: chains on Avalanche are quiescent, meaning that if there is no activity, there are no blocks produced. The opposite is also true, if there is a great amount of activity, blocks are produced very fast. Because of this, we should not measure the passage of time by the number of blocks that are produced. The results will not be accurate, and contracts may be manipulated by third parties. ==> Instead of block rate, we should (as we actually do), measure time simply by reading the timestamp attribute of the produced blocks, as timestamps are guaranteed to be monotonically increasing and to be within 30 seconds of the real time.

  • Finality: on Ethereum, the blockchain can be reorganized and blocks can be orphaned, so we cannot rely on the fact that a block has been accepted until it is several blocks further from the tip (usually, it is presumed that blocks 6 places deep are safe). This is not the case on Avalanche: blocks are either accepted or rejected within a second or two. And once the block has been accepted, it is final, and cannot be replaced, dropped, or modified. ==> So, the concept of 'number of confirmations' is not used on Avalanche. As soon as a block is accepted and available in the explorer, it is final.

  • Gas price: Gas on Avalanche is burned. Validators don't keep the gas for themselves (they get rewarded for staking), so the dynamics of 'gas wars' where higher-priced transactions are included first is non-existent. ==> Therefore, there is never a need to put a higher gas price on your transactions.

  • RPC public nodes actually being load-balancers: Using eth_newFilter RPC method on the public API server, may not behave as expected because the public API is actually several nodes behind a load balancer. If we make an eth_newFilter call, subsequent calls to eth_getFilterChanges may not end up on the same node as the first call, and we will end up with undefined results. Besides, if we needed log filtering functionality, we should also use a websocket connection, to ensure that the client (e.g. web3 gateway), is always talking to the same node behind the load balancer. ==> Alternatively, we could use the eth_getLogs method, or run our own node and make API calls to it.

[guidiaz]

Avalanche Transaction Fees:

• The fee is paid in AVAX. The whole tx fee is burned and destroyed for ever, always.

• When you issue a tx through Avalanche's API, the tx fee is automatically deducted from one of the address we control.

• Different types of txs require payments of a different tx fee. For instance, a simple send in Avalanche C-Chain requires at least 0.001575 AVAX.

• The Avalanche C-Chain uses an algorithm to determine the "base fee" for a tx. The base fee increases when network utilization is above the target utilization and decreases when network utilization is below the target.

• Dynamic Fee Transactions:

  • Tx fees for non-atomic txs are based on Ethereum's EIP-1559 style Dynamic Fee Transactions, which consists of a gas fee cap and a gas tip cap.
  • The fee cap specifies the maximum price the tx is willing to pay per unit of gas. The tip cap (calso called the 'priority fee') specifies the maximum amount above the base fee that the tx is willing to pay per unit of gas. Therefore, the effective gas price paid by a tx will be min(gasFeeCap, baseFee + gasTipCap). Unlike in Ethereum, where the priority fee is paid to the miner that produces the block, in Avalanche both the base fee and the priority fee are burned. For legacy txs, which only specify a single gas price, the gas price serves as both the gas fee cap and the gas tip cap.
  • Use the eth_baseFee API method to estimate the base fee for the next block. If more blocks are produced in between the time the pending tx gets constructed and is finally included in a block, the base fee could be different from the base fee estimated by the API at that moment, so it's important to treat this value as an estimate..
  • Next, use eth_maxPriorityFeePerGas API call to estimate the priority fee needed to be included in a block. This API call will look at the most recent blocks and see what tips have been paid by recent txs in order to be included in the block.
  • Based on this information, we can specify the gasFeeCap and gasTipCap to our liking, depending on how we prioritize getting a tx included as quickly as possible vs. minimizing the price paid per unit of gas.

[aesedepece]

Thanks for all the info @guidiaz. I have already reached out to my contact in Ava Labs to get the ball rolling in this cooperation.

[guidiaz]

Despite the fact there's a AvalancheJS sdk, the integration could be handle with little adaptation on the web3-jsonrpc-gateway/ethers module. See https://github.com/witnet/web3-jsonrpc-gateway/pull/22

[guidiaz]

AVAX/USD-6 has been prepared and deployed into Avalanche Fuji. See https://github.com/witnet/witnet-price-feed-examples/pull/70

[guidiaz]

New docs site has been updated with deployed addresses in Avalance Fuji:

• Price feeds: https://docs.witnet.io/smart-contracts/witnet-data-feeds/contract-addresses/avalanche-data-feeds
• Randomness oracle: https://docs.witnet.io/smart-contracts/witnet-randomness-oracle/contract-addresses
• Witnet Request Board: https://docs.witnet.io/smart-contracts/apis-and-http-get-post-oracle/contracts-addresses

[aesedepece]

We can consider this done!