Are fees denominated in NEAR or is there an ETH token equivalent for fees that RPC operators would then collect in return for sending the wrapped transaction (thereby spending NEAR)?
The whole point of the RPC (relayer) is that Aurora is completely abstracting from NEAR, and creating a fully compatible Ethereum ecosystem. The transaction that is being executed on chain will be consuming NEAR to pay for the gas, but this will be abstracted away by the RPC, which will charge the equivalent in ETH and pay the NEAR tokens itself.
So basically when a user signs a transaction, it includes a fee that is sent to the RPC (the Relayer submitting the transaction to NEAR). Gas fee is paid with NEAR token by the relayer, but they get some ETH back. Currently the fee being charged by Aurora RPC is 0, so basically transactions can be sent for free right now, this will change in the future for Aurora RPC, but others can run the same RPC and use different policies.
Related
Gas costs for even a simple contract deployment are astronomical. If I spin up my own node and connect directly to it can I deploy on that node and avoid the gas fees?
Can I avoid gas fees by running my own Ethereum node?
Simple answer: No.
A node accepts the transaction, stores it in its mempool, and relays it to other nodes so that they can also store it in their mempool. There's nothing related to gas costs at this point.
Theoretically you could deploy a contract for "free" by running your own miner. But that's impossible without professional hardware costing very large amounts - many times more expensive than what you'd save on the gas fees.
However, in a block that you mined, you could include a transaction deploying a contract with 0 gas price. This sometimes happens - miners do occasionally put their own 0-priced transactions in their own blocks. But apart from that, no miner would accept your transaction with 0 gas price (or any transaction priced lower than the current market rate), as that wouldn't be profitable for them.
If I were to create my own Ethereum based crypto token named "ExampleCoin" with a supply of 1,000,000,000 and decided to distribute it to users for playing my game, would I need to pay a gas fee each time I give a user some ExampleCoin?
And if I had an in game store where users can make purchases with ExampleCoin, would a gas fee need to be paid in order to send ExampleCoin from the user to the game?
Gas is like gasoline to the Ethereum network; whenever we interact with the blockchain and affect its state, we must pay the fee required to perform the computations and process the transaction [1]. Each action such as storing values, sending tokens, adding integers etc. has associated cost in gas units [2]. The total gas cost for a transaction is multiplied by a gas price [3] to get the gas, or transaction, fee.
The transaction in which the ExampleCoin contract allocates some ExampleCoin tokens to a user, will be initiated by the user who will have to pay the required gas fee. Thus, it is the user who will initiate the transaction which will allocate the tokens to him, and thus he will pay the gas fee.
Similarly, when the user makes purchases with ExampleCoin, he is making a transaction affecting the state of the blockchain and thus incurring gas cost; so, he will have to pay the gas fee.
The bottom line is that whoever makes a transaction will have to pay the required gas fee. In this case, it would be the user, and not your contract, who pays the gas fee.
It is because of the increasing gas prices and thus transaction fees on the Ethereum network that solutions like sidechains, and other blockchains focusing on low transaction fees such as Solana have been developed. Thus, as a smart contract/ dapp developer, one has to comprehensively ascertain the business logic of one's application and decide which network to deploy it on, keeping the end user's experience in mind.
[1] See these explainers on gas and transactions:
https://ethereum.org/en/developers/docs/gas/ https://ethereum.org/en/developers/docs/transactions/
[2] See page 27 of the Yellow Paper for a list of operations and associated gas cost in gas units. For example, the base gas cost for every transaction is 21000 gas units: https://ethereum.github.io/yellowpaper/paper.pdf
[3] This is the amount in ETH we are willing to pay to the miner, per gas unit, as incentive to include our transaction in the next block. The higher the gas price, the more quickly our transaction is picked up by miners and mined.
If this is your private network and you do not want to use the gas mechanism to pay for transactions, then use Quorum - it does not require a transaction fee, and smart contracts are similar to Ethereum.
If you want to use Ethereum in your network, then you will have to come up with a mechanism for automatic distribution and compensation of Eth on user accounts. The simplest option is to give 100,000 Eth to the user's account when registering.
I'm working on sending transactions from one address to another on the goerli testnet and all transactions so far are not confirming. They have been staying in a pending state: https://goerli.etherscan.io/tx/0x056187763bac9adc8696fa0554c26b2f0e8ac48601dd4e5f03a30536d6597bf0
Did I do something wrong? I see the transaction in the etherscan.io/tx, but do I need some sort of callback handler?
Is this because there are not enough miners on the goerli testnet? Is Kovan the best testnet for ethereum dapp/smart contract development where transactions are being confirmed more often?
Any help is appreciated.
The linked transaction offers gas price of 0.000000002 Gwei (which is 2 wei). Usual current gas price on the Goerli network is 2 Gwei (1 billion times larger).
So it just seems that your sending script incorrectly calculates the decimals for the gas price.
Most miners order transactions by the gas price. So if there were more miners or less pending transactions, there would be a higher probability of this transaction making it to the block. But in the current situation, you need to raise the gas price of your transaction in order to compete with the other pending transactions.
If you want to replace the gas price on this particular transaction, you can send a new one with the same nonce but higher gas fee.
Is it possible to store gas that is not used inside a contract, so it can be used at a later time (presuming it is possible to require a certain amount of gas calling a function)?
I am trying to write a contract that requires user input and does something based upon that input at a later moment in time that will require gas.
As it does not sound really attractive to pay that gas out of the contract owners pocket I am looking for a way to make the user of the contract pay for the gas it needs to complete the request.
In fact, it is really possible to store gas in a contract for later use.
There are some operations in EVM that can return some gas that was payed before:
SSTORE: changing storage value from non-zero to zero releases 15000 gas
SELFDESTRUCT: destroying contract releases 24000 gas
That means that e.g. storing some value requires 20k gas, but deleting it form storage requires only 5k gas and releases 15k gas for later usage in the same transaction. Actually this is a reward for clearing up blockchain storage.
You can get more details by searching "refund" in Yellowpaper.
There is GasToken project that uses this very feature to store gas in contract when it is cheap and release (and use) when it is expensive.
To be clear, I don't think this allows user to issue transactions without paying gas at all.
Seems like you have mixed up a little bit the meaning of gas.
The gas is the Ether you have to pay to have your transaction mined. The gas is always paid by the address that calls the function(Contract) and not from the Contract itself or the owner of the Contract so it doesn't come out of the owners pocket. Also gas is basically ether so "storing gas" is to store Ether in a contract but you cannot store the gas that is used to mine the transaction. If you want to store Ether you have to send Ether to the Contract or have the users send Ether when they call a function.
I have recently downloaded the GUI wallet, and it gives the option to create contract based wallets and connect to them to a main account. What is the difference between using a contract based wallet and an account? And what should be used to store my ether?
Contract-based wallets are more robust and can be more secure. For example, a contract can be setup to require transfers over a certain threshold to be approved my multiple people/keys. Even if these keys all reside on your local computer, having to compromise even a slightly-improved 2 of 3 can provide far greater security than a single key alone.
Additionally, contracts benefit from transaction receipts, which contain a permanent log of all events. This makes it much easier to inspect the state and verify the history of a contract. For example, when a new transaction request is initiated against a wallet contract requiring multiple signatures, an event log for "ConfirmationNeeded" with the operation ID will be added. After the operation has received the appropriate number of signatures, a "MultiTransact" might occur containing the recipient, value, and associated data with the transaction.
Standard accounts benefit from none of this and can only send transactions, not respond autonomously.
Here are advantages and disadvantages for comparison.
Advantages of contract-based account wallets:
Funds are not stored on a single key.
You can cycle through management keys.
Mutisig functionality; only execute a transaction on majority rule (eg. Gnosis Multisig)
Allows for account recovery, in case your management keys are lost (eg. Argent).
Set transfer and withdraw limits enforced by the contract.
You can have access controls for keys, meaning you can restrict what methods a key can invoke. Useful when you want to delegate control to someone else but restrict what they can do.
Batched transactions; execute multiple transactions as 1 atomic transaction.
Defi protocol composition; easily integrate with other smart contracts (eg. one-click DAI saving rate accounts)
Meta transactions: pay your transaction costs using a different asset, like a token (eg. Gas Station Network). Relayers may also offer free transactions (eg. Authereum)
Disadvantages of contract-based account wallets:
Contract are susceptible to attacks; people write buggy code all the time (eg. Parity hack). An Externally-owned account (EOA) can't be hacked because there is no code to hack.
Backward incompatible features may render funds locked if contract not properly written. (eg. Istanbul hardfork gas cost changes)
Deployment costs; unlikes key pairs which doesn't cost anything to generate, there's a fee cost for deploying contract-based accounts.