Closed sync-by-unito[bot] closed 3 years ago
➤ Yulia Timchenko commented:
Evgeniy Zherdzitskiy - does it require some logs?
➤ Automation for Jira commented:
Corresponding Pull Request https://github.com/skalenetwork/skale-manager/pull/565
➤ Ganna Kulikova commented:
Not critical for the schains launch
➤ Vadim Yavorsky commented:
We discussed with the guys that we can slightly change the logic of the refund. Now the ether will return not in the transaction itself, but in the next one that someone on the network calls. To do this, we will store the structure: node address, balance before the transaction, who should pay for the transaction. Thus, we will be able to return exactly as much as was spent. But for this to work as it should, we need to prevent nodes from withdrawing funds from the wallet. To do this, we need to prohibit withdrawals from the wallet at the SGX level. If the validator wants to withdraw his funds from the node's wallet, he will need to transfer them to the contract and then withdraw them.
➤ Chadwick Strange commented:
interesting - Vadim Yavorsky when you say “store” where will this happen and how expensive will it be?
➤ Chadwick Strange commented:
and for clarification: do you mean if a node requests getBounty in Month 1 - then the replenishment transaction is not executed until the subsequent getBounty transaction is executed in Month 2?
➤ Chadwick Strange commented:
Example Doc changes:
IntroThe self-recharging wallet system reimburses transactions during the subsequent transaction. For example, a node that executes getBounty in July, will be reimbursed for the getBounty transaction when getBounty is executed in August. This delay is done to ensure accurate accounting of transaction costs.
Using node walletsValidators cannot directly withdraw funds from their node wallets. To withdraw funds from node wallets, first transfer them to the self-recharging validator wallet using the node-cli skale wallet send [YOUR-SELF-RECHARGING-VALIDATOR-WALLET] [AMOUNT]
Ebru Engwall Dmitry Tkachuk please comment?
➤ Vadim Yavorsky commented:
Chadwick Strange No, getBounty transaction will be reimbursed after any transaction on mainnet that requires gas replenishment. For example: Tx1 - > getBounty(1); node 1 is caller After execution Tx1 we store
Tx2 -> broadcast(data); node 2 is caller In tx2 we reimburse previous transaction tx1, because we know all the necessary data for this. Also as in tx2 we store data
And so on, in TXn we reimburse TXn-1
➤ Alex Danko commented:
works for manager: 1.8.1-develop.4
broadcast: https://rinkeby.etherscan.io/tx/0x733b83d4f3509a884c6b59484779596e1669ee4cfbb9cfa89ef0978d48c02d31 ( https://rinkeby.etherscan.io/tx/0x733b83d4f3509a884c6b59484779596e1669ee4cfbb9cfa89ef0978d48c02d31 ) alright: https://rinkeby.etherscan.io/tx/0xa6bf1a5aeb2abaa893a8d375dd5d2b74fde7324b1ae33dcfb7e757296e8b23e0 ( https://rinkeby.etherscan.io/tx/0xa6bf1a5aeb2abaa893a8d375dd5d2b74fde7324b1ae33dcfb7e757296e8b23e0 )
Preconditions Skale manager: 1.8.0-beta.1
Step to reproduce Create schain Observe tx on etherscan
Actual result For now we have gap in broadcast 26-29% and ~50% during allright transactions. Tx example: Broadcast: https://rinkeby.etherscan.io/tx/0x1dd0a2c9473c0100f46a92498653d70d724e20dea98001ecad15855e6e935777
Alright: https://rinkeby.etherscan.io/tx/0x65e935932b7a664af0e544890b43da3714fde24b54128bd66221ca36439cc0f2
┆Issue is synchronized with this Jira Bug