TIP: 0030
Title: EOS genesis snapshot on-chain
Authors: Viterbo Rodríguez
Status: Draft
Type: Protocol
Created: 2018-10-27
Discussion: <url>
This TIP proposes that the Telos Foundation should create a smart contract (which I am going to refer to as eossnapshot) and then load the EOS genesis snapshot once and for all. This eossnapshot contract then should provide services to query information for a specific account. That service may be used to perform futures airdrops (based on the snapshot information) without incurring in resource costs (RAM and bandwidth).
I plan to deploy more than one token on the blockchain and I will perform an airdrop for each one. The problem I face is that I will have to pay for the airdrop resources usage several times (once for each token). This proposal delegates that cost to the Telos Foundation, who will pay for it just once and then serve it for free to all new Tokens.
Although it is not mandatory to perform an airdrop, most of the new Tokens on Telos will do so and that means a significant expense for those who perform this task.
One solution that is already being handled is to wait for each user to "register" and thus pay the cost of using the RAM, but this is a problem since it means to wait from every user to take action.
If the Telos Foundation takes care of the RAM costs of storing the EOS snapshot data as an immutable balance token on-chain, that info can be used in order to resolve the balance of any unregistered account but includding the its airdrop balance.
This will be another great argument when talking about how developer-friendly the TELOS blockchain is. Plus the cost of implementing this solution will be paid once by Telos Foundation and will be usefull for everyone (not only airdrops).
The following pseudo code is an abstract proposal for the eossnapshot smart contract that will implement the eosio.token api parcially. The whole idea is to replicate the snapshot that currently exist on Ethereum blockchian as EOS ERC20 Token and load it on a token-like smart contract on the TELOS blockchian. This way everyone may get everybody's balances like in any other token. This information may be used from real new Tokens to perform an airdrop without actually storing anything on memory, reducing RAM costs to zero.
CONTRACT eossnapshot : public contract {
public:
// hardcoded issuer should be "eossnapshot"
// hardcoded max_supply should be "1000000000.0000 GENESIS"
ACTION create();
// should be called once for every account in the snapshot
ACTION issue(name to, asset quantity, string memo );
// this token is inmutable. So, there's no transfer
// NO_ACTION transfer(name from, name to, asset quantity, string memo);
static asset get_supply();
static asset get_balance(name owner);
private:
TABLE account {
asset balance;
uint64_t primary_key() const { return balance.symbol.code().raw(); }
};
TABLE currency_stats {
asset supply;
asset max_supply;
name issuer;
uint64_t primary_key() const { return supply.symbol.code().raw(); }
};
typedef eosio::multi_index< "accounts"_n, account > accounts;
typedef eosio::multi_index< "stat"_n, currency_stats > stats; // should have only one row globally
};
Let's say I want to create a NEW token with a maximum supply of "500000000.0000 NEW" (500 Million NEW tokens). I also want to perform an airdrop (with ratio 1:2) but I want to cap every airdrop at (let's say) 50K and more important, without any RAM cost.
Immediately after the token smart contract is created, its tables will be empty. But if I ask for any account's balance, the answer should be the airdrop instead of zero. To achieve this, the get_balance function should query the account's balance from the eossnapshot contract, and (in this example) divide it by 2 and finally capping it at 50K. This way each Token can implement the airdrop with any complex logic.
At some point the people will use their NEW Tokens and transfer them to some other account. In this moment is when the actual airdrop take place because we can charge the user as the RAM payer (for both, sender and receiver RAM usage). That means that the first transfer of all accounts will trigger the actual airdrop and store the final sender's balance and the receiver's balance *.
| account | final balance |
|---|---|
| sender | sender's airdrop minus transfer |
| receiver | receiver's airdrop plus transfer |
- if the receiver has already paid for his or her RAM, the sender will not be charged.
...
This TIP proposes to delegate to Telos Foundation the responsability of keeping abailable for everyone the EOS snapshot data. This way the aidrops will cost much less and potencialy atract developers to TELOS blockchain.
N/A
...