Kevin Jeong(kevin.j@onther.io, Onther Inc.)
Thomas Shin(thomas.s@onther.io, Onther Inc.)
Jason Hwang(jason.h@onther.io, Onther Inc.)
Carl Park(carl.p@onther.io, Onther Inc.)
PoC1 is the transaction execution model which is competible with Ethereum Virtual Machine. The purpose of this project is to provide the transaction processing procedure, maintaining ethereum's GAS system, delegates GAS from transactor to decentralized autonomous agent(smart contract) defined in blockchain.
In PoC1, we achieved an improvement from a simple structure, GAS and value(ETH) paid from only to transactor, to multiple structure the burden of fee is supported by "stamina contract" in a means of "Stamina". Stamina is periodic-rechargable state variable and it's comsumption is keep tracked and managed by blockchain rules.
As a result, users do not need to concern about the "keeping balance maintanance activities". It also facilitates service provider to create a more user-friendly decentralized application(dApp). This will accelerate the emergence of killer apps, pushing to expand the decentralized ecosystem futher.
Ethereum imposes fee on all computing operations to prevent unauthorized use of the network. This fee is calculated as a special unit called Gas and it is a time-space cost[2] on the Ethereum network.
The Ethereum blockchain avoids denial of service attacks through this commission model and solves the problem of distributing limited resource; 'Right of state transitions in blockchain'. The important point is that the transactor always maintains a certain level of balance to generate the transaction paying the GAS Limit * GAS Price. Transactor sends a transaction "always" has to bear these costs. It extremely reduces the usability of DApps implemented on Ethereum blockchain.
In PoC1, we want to design an Execution Model which enhances the user experience. It is expected to provide a ground for user-friendly (accessibility / usability) application development environment.
The words defined in PoC1 are as follows(Some of denotations came from ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER[1]):
0x00
or 0xFF...FF
(2^160 - 1
) with signature v = r = s = 0
.value + gasLimit * gasPrice
(Expenses that are charged before executing EVM.).tx.gasLimit * tx.gasPrice
.The system we design in this chapter is largely divided into two parts:
The transaction fee of the delegator is purchased by the delegatee in the form of stamina, alleviating the delegator gas burden. A stamina can be obtained by depositing asset on a stamina contract
, and an account that deposits the stamina of a delegatee is called a depositor
.
The deduced stamina does not mean disappearing forever, but it will be recovered after a certain period of time. It is stamina recover
in PoC1. The stamina requires a period of time to recover, and it is recover epoch length
. Every epoch, stamina is newly charged as much as amount deposited.
The stamina balance expressed as follows:
A delegator is denoted as
When the delegatee and the delegator satisfy the above equation, they become a stamina pair
.
Stamina contract provides the following functions:
A delegatee can designate a delegator. Only a delegatee can designate, whereas a delegator can not. In addition, a delegatee can designate multiple delegators.
The delegatee calls stamina contract's setDelegator()
function to designate the delegator.
function setDelegator(address delegator)
external
onlyInitialized
returns (bool)
{
address oldDelegatee = _delegatee[delegator];
_delegatee[delegator] = msg.sender;
emit DelegateeChanged(delegator, oldDelegatee, msg.sender);
return true;
}
To increase the stamina, the depositor must call the deposit()
function of the stamina contract.
For example, let's assume account A, B exist. If account A calls deposit()
function to add stamina of B, B's stamina increased.
function deposit(address delegatee)
external
payable
onlyInitialized
returns (bool)
{
require(msg.value >= MIN_DEPOSIT);
uint totalDeposit = _total_deposit[delegatee];
uint deposit = _deposit[msg.sender][delegatee];
uint stamina = _stamina[delegatee];
require(totalDeposit + msg.value > totalDeposit);
require(deposit + msg.value > deposit);
require(stamina + msg.value > stamina);
_total_deposit[delegatee] = totalDeposit + msg.value;
_deposit[msg.sender][delegatee] = deposit + msg.value;
_stamina[delegatee] = stamina + msg.value;
if (_last_recovery_block[delegatee] == 0) {
_last_recovery_block[delegatee] = block.number;
}
emit Deposited(msg.sender, delegatee, msg.value);
return true;
}
In contrast, stamina contract's requestWithdrawl()
, withdraw()
function called to reduce the stamina of the delegatee. At this point stamina shrinks and depositor's balance is increased as much as stamina reduced, accordingly.
In order for the depositor to withdraw, it goes through two steps:
requestWithdrawl()
functionrequestWithdrawal()
function. When it is called, the stamina of the delegatee is deducted by the requested amount, and this record remains in stamina contract.withdraw()
functionwithdraw()
function to withdraw the account balance as much as the stamina recorded in previous step.function requestWithdrawal(address delegatee, uint amount)
external
onlyInitialized
returns (bool)
{
require(amount > 0);
uint totalDeposit = _total_deposit[delegatee];
uint deposit = _deposit[msg.sender][delegatee];
uint stamina = _stamina[delegatee];
require(deposit > 0);
require(totalDeposit - amount < totalDeposit);
require(deposit - amount < deposit);
_total_deposit[delegatee] = totalDeposit - amount;
_deposit[msg.sender][delegatee] = deposit - amount;
if (stamina > amount) {
_stamina[delegatee] = stamina - amount;
} else {
_stamina[delegatee] = 0;
}
Withdrawal[] storage withdrawals = _withdrawal[msg.sender];
uint withdrawalIndex = withdrawals.length;
Withdrawal storage withdrawal = withdrawals[withdrawals.length++];
withdrawal.amount = uint128(amount);
withdrawal.requestBlockNumber = uint128(block.number);
withdrawal.delegatee = delegatee;
emit WithdrawalRequested(msg.sender, delegatee, amount, block.number, withdrawalIndex);
return true;
}
function withdraw() external returns (bool) {
Withdrawal[] storage withdrawals = _withdrawal[msg.sender];
require(withdrawals.length > 0);
uint lastWithdrawalIndex = _last_processed_withdrawal[msg.sender];
uint withdrawalIndex;
if (lastWithdrawalIndex == 0 && !withdrawals[0].processed) {
withdrawalIndex = 0;
} else if (lastWithdrawalIndex == 0) { // lastWithdrawalIndex == 0 && withdrawals[0].processed
require(withdrawals.length >= 2);
withdrawalIndex = 1;
} else {
withdrawalIndex = lastWithdrawalIndex + 1;
}
require(withdrawalIndex < withdrawals.length);
Withdrawal storage withdrawal = _withdrawal[msg.sender][withdrawalIndex];
require(!withdrawal.processed);
require(withdrawal.requestBlockNumber + WITHDRAWAL_DELAY <= block.number);
uint amount = uint(withdrawal.amount);
withdrawal.processed = true;
_last_processed_withdrawal[msg.sender] = withdrawalIndex;
msg.sender.transfer(amount);
emit Withdrawn(msg.sender, withdrawal.delegatee, amount, withdrawalIndex);
return true;
}
The stamina of the delegatee is subtracted to purchase the delegator gas cost, and the remaining gas is returned to the delegatee after the transaction execution.
When the delegator purchases the delegatee gas cost, the stamina of the delegatee is deducted. The stamina deduction is made by calling subtractStamina()
function from the NULL_ADDRESS.
function subtractStamina(address delegatee, uint amount) external onlyChain returns (bool) {
uint stamina = _stamina[delegatee];
require(stamina - amount < stamina);
_stamina[delegatee] = stamina - amount;
return true;
}
}
The subtractStamina()
function has an onlyChain
modifier. Functions with this onlyChain modifier can only be called directly by the NULL_ADDRESS, and can not be called by other accounts.
modifier onlyChain() {
require(msg.sender == address(0));
_;
}
After purchasing the gas-upfront cost with stamina and processing the transaction, the remaining gas is refunded to the delegatee. This is also done by calling the stamina contract function from the NULL_ADDRESS which will call the addStamina()
function. Futhermore, the addStamina()
function includes logic to check recovery epoch
.
function addStamina(address delegatee, uint amount) external onlyChain returns (bool) {
if (_last_recovery_block[delegatee] + RECOVER_EPOCH_LENGTH <= block.number) {
_stamina[delegatee] = _total_deposit[delegatee];
_last_recovery_block[delegatee] = block.number;
_num_recovery[delegatee] += 1;
return true;
}
uint totalDeposit = _total_deposit[delegatee];
uint stamina = _stamina[delegatee];
require(stamina + amount > stamina);
uint targetBalance = stamina + amount;
if (targetBalance > totalDeposit) _stamina[delegatee] = totalDeposit;
else _stamina[delegatee] = targetBalance;
return true;
}
The stamina of the delegatee will eventually be exhausted. But the depleted stamina can be recharged in the next epoch. It means the delegatee's stamina is reusable.
Stamina recovery condition appears at the beginning of addStamina()
function. If current epoch meets recovery condition, then total amount deposited will be regained.
if (_last_recovery_block[delegatee] + RECOVER_EPOCH_LENGTH <= block.number) {
_stamina[delegatee] = _total_deposit[delegatee];
_last_recovery_block[delegatee] = block.number;
_num_recovery[delegatee] += 1;
return true;
}
Gav Wood defined five conditions for testing the intrinsic validity of a transaction in ETHEREUM: A SECURE DECENTRALISED GENERALIZED TRANSACTION LEDGER [1].
In this transaction model, we re-defined condition 5:
If upfront cost is defined as:
The above equation is divided into gas-upfront cost and value-upfront cost.
In this case, the transaction validity can be expressed as follows:
The non-delegated execution is the same as the transaction processing in Ethereum, and it is followed:
First of all, check whether the delegator is included in the stamina pair.
Following code block is a pseudo-code representation of 2.2.3 Delegated Execution
chapter.
The tx_traditional_execute()
function contains the pseudo-code for the non-delegated execution of the traditional ethereum, and the tx_delegated_execute()
function contains the pseudo-code for the delegation execution.
def tx_traditional_execute(from, to, value, gasLimit, gasPrice, data) :
# 1. check `from` can pay upfront cost
balance = getBalance(from)
assert balance >= value + gasLimit * gasPrice
# 2. substract upfront cost(tx.value + tx.gasLimit * tx.gasPrice)
substractBalance(from, balance - value - gasLimit * gasPrice)
# 3. execute EVM
executeVM(from, to, value, gasLimit, gasPrice, data)
# 4. collect refunded gas
addBalance(from, gasRemained * gasPrice)
def tx_delegated_execute(from, to, value, gasLimit, gasPrice, data) :
# 0. check if (delegator, delegatee) pair exists. execute EVM.
# getDelegatee() returns <delegatee address>
# or it returns <None>
delegatee = staminaContract.getDelegateeAddress(from)
# 1. case where delegatee exist
# Check, if `to` has delegatee check upfront cost(only gasLimit * gasPrice)
if delegatee and staminaContract.balanceOf(delegatee) >= gasLimit * gasPrice:
# 1-1. check if `from` can pay upfront cost(only value)
assert getBalance(from) >= value
# 1-2. subtract upfront cost(only gasLimit * gasPrice) from delegatee
staminaContract.subtractBalance(delegatee, gasLimit * gasPrice)
# 1-3. substract upfront cost(only value)
substractBalance(from, value)
# 1-4. execute EVM
executeVM(from, to, value, gasLimit, gasPrice, data)
# 1-5. collect refunded gas to delegatee
staminaContract.addBalance(delegatee, gasRemained * gasPrice)
# 2. case where delegatee does not exist
else:
# Execute tx tranditional way
tx_traditional_execute(from, to, value, gasLimit, gasPrice, data)
Traditional Ethereum | Delegated Model | Remarks | |
---|---|---|---|
Account to buy upfront cost | transactor | transactor or delegatee | |
Account to buy gas-upfront | transactor | transactor or delegatee | |
Account to buy value-upfront | transactor | transactor | |
Minimum EVM Execution | 1 | 3 |
Link : https://hackmd.io/s/HJrS5IxIm
In PoC 1: EVM Compatible Gas In the Delegated Transaction Execution Model, we proposed an execution model to solve the usability problem, so that users do not have to worry about transaction fees. And this model also endures network attacks such as DoS.
The main feature of PoC1 is the delegation of transaction fees between stamina pair's accounts. To delegate commission, PoC1 added a new concept "Stamina". Once the stamina runs out, delegator can pay for the transaction fee on their own state balance. And it can still prevent any network attacks, because regardless of commission type, weather is stamina or balance, fees are charged for every transaction. Also, the delegatee can prevent the malicious delegator from consuming the stamina by releasing the pair designation when delegatee detects an abnormal behavior. If there is a dapp running on this model for a specific purpose, the service provider will have a number of delegatee and set the service users as delegator. Dapp's initial users don't have to worry about the transaction fee. This suggests that the proposed model of PoC1 is much more usable than the traditional execution model of Ethereum.
As we have seen in the 2.2.5 Comparison with the existing Ethereum execution model
, this model runs EVM at least three times per transaction, so if it is applied to mainnet, it becomes slower than before. Therefore, it is more suitable to use in private chain or sidechain. In order to solve this issue, we will discuss in PoC2: Plasma EVM on how to use the proposed architecture applied in sidechain.