Closed aesedepece closed 2 years ago
https://docs.avax.network/learn/platform-overview/
Avalanche Blockchain Consensus:
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:
Developing and deploying contracts:
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.
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:
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.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..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.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.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.
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
AVAX/USD-6 has been prepared and deployed into Avalanche Fuji. See https://github.com/witnet/witnet-price-feed-examples/pull/70
New docs site has been updated with deployed addresses in Avalance Fuji:
We can consider this done!
https://docs.avax.network/: