Hello, this is eosBLACK team!
Following the last ‘How to do Airdrop’, the story we are going to tell you about is the EOSIO account name auction. Please take a look at how EOSIO’s auction system works and think about which part could be improved better.
Let’s check Daniel Larimer’s proposal first!
Dan’s suggestion
Prior to launching the mainnet, Dan proposed a “name auction house” to prevent the unchanging of names as follows:
https://github.com/EOSIO/eos/issues/3189
Simply put,
1.The name, xyz.com, can only be created by someone with an account called com
2.For the “premium name” that can affix “.”, the person who proposed the maximum value can have ownership once a day
The “Top Name Bids” on the bottom right of eosflare.io is the system that Dan has proposed. I know that bidding is done every 24 hours under this system, but when I saw there was no change even after a few days, my curiosity drove me to figure out what happened.
First, let’s learn about EOS accounts
To talk about the name bidding, I think you should know about what is EOS account. EOS accounts are required to consist of 12 characters made of lower-case English letters, a through z, numbers 1 through 5, or a combination of the two. You naturally will come to grumble, “Do we have to make it 12 characters?” during this process of course. If the name that is familiar is less than 12 characters, I have to insert meaningless characters to make it 12 characters.
But then the question arises, “Do I have to make an account of 12 characters?”
For accounts under 12 characters, EOS provides a system where participants can suggest their desired prices by submitting them during an auction. The rule is that only one account name with the highest bidding price can be auctioned off every 24 hours among all submitted account names. In other words, the system requires a bidding to be successful only when the suggested bidding price is the highest among all other account bidding prices suggested by people.
It means that you can make a 12-character general account or if you do not want to fill in 12 characters, then you would have to buy it through an account name auction. We may then think, “Aha! we can create our own premium account name, like a domain, other than our regular account!”
The reason we participate in such an auction, even while paying exorbitant costs, is that we earn the right to create a subaccount, like a domain, with the account name as the suffix.
Examining the system further
However, commonsensically, premium names have different values, so we were assured that the person who submitted the maximum value for each name would be the winner. However, I began to grow a sense of doubt from the fact that the person who suggested the maximum value among the entire list becomes the winner of the day in the actual implementation. I do not understand how there is only one winner among numerous name bids. Moreover, even if you have ownership, the name auction coming to a halt is inevitable if you do not create an account.
How the actual process works:
1.Users bidding a favorite name requires transferring the name and bidding amount by using the bid name action of the eosio contract
2.Information is stored in the name bids table
3.The onblock function in producer_pay.cpp is executed every minute
4.After one day has passed since last ownership acknowledgement time
5.Using the highbid index of this name bids table, select the top-level bidder and change the bid amount to a negative number
6.For information with a negative bid amount, ownership is acknowledged to prevent further participation in the bid
Multi-index name bids are based on the name bid structure in eosio.system.hpp. However, the highbid index of this structure returns the negative value of the structure member high bid for sorting in reverse order. The onblock function selects and uses the first value of this index. This value is always returned if the highest value is already set to be negative.
https://github.com/EOSIO/eos/blob/v1.2.1/contracts/eosio.system/producer_pay.cpp#L52
In other words, as long as there is such bidding information, future ownership assignments will no longer work.
The severity of this problem is more apparent when you look at the name bids table in the current mainnet state (08.16.2018 T04:56:32 UTC).
At the very top, the bid value named app is negative. Ownership has been granted to the bidder, f2poolshenyu. It is difficult to figure out the date with a numeric value, so let’s take a look at bid name info.
Ownership has been likely granted from at least after August 4, 2018, and since the bidder has not created an account with the bidden name, the lower bidders have not been granted ownership for 12 days.
The final bid of the fifth bidder, dex, was made as long ago as last month.
Currently, this problem has been fixed by obtaining a positive value from the high bid index to the repository called, eosio.contract, and is awaiting distribution.
https://github.com/EOSIO/eosio.contracts/blob/v1.2.0/eosio.system/src/producer_pay.cpp#L57
Considering points of improvement
I was dissatisfied that the contributors managing the EOSIO repository simply closed the issue saying that it’s just a function, without any explanation and concern, despite my raising the problem as an issue.
https://github.com/EOSIO/eos/issues/5140
Anyway, if it is operated in the way that the maximum value in the entire name bidding is considered to be the winner, I am wondering if people, who plan to prepare an eos-based DApp and use a sub-account separated by a “.,” will be able to formulate a normal business plan. I do not understand why there is no confirmation about when the ownership of the name that I requested is granted.
For now, even if the prepared system contracts are distributed via the consultation of BPs, there is no choice but to wait for a day after a bid, with a value higher than “6050.0002 EOS,” in order to quickly ensure that I get the name I want.
As a suggestion, I think that many of the complaints from users preparing DApp related to the premium names in eos will only be resolved once annotating day-to-day checks above the aforementioned code.
https://github.com/EOSIO/eosio.contracts/blob/v1.2.0/eosio.system/src/producer_pay.cpp#L54
It is because the value of the individual premium name, rather than the integrated value, will be recognized, and above all, it will be possible to predict when the premium name is secured.
Conclusion
This was an opportunity to put EOSIO into perspective while learning about the account name bidding system, which I might just overlook. In the future, I will keep a journal of my experiences during development and would appreciate your feedback. Be sure to stay tuned!
Thank you.
Yours sincerely,
eosBLACK team.
eosBLACK Homepage : http://eosblack.io
eosBLACK Koreos : http://koreos.io/eosBLACK
eosBLACK Medium : https://medium.com/@eosblack
eosBLACK steemit : https://steemit.com/@eosblack
eosBLACK Facebook : https://www.facebook.com/eosBLACKTeam
eosBLACK twitter : https://twitter.com/EOSBLACK_IO
eosBLACK Telegram(Korean) : https://t.me/eosBLACK_Korea
eosBLACK Telegram(English) : https://t.me/eosBLACK_English
White Paper (Korean) : http://bitly.kr/nap2
White Paper (English) : http://bitly.kr/MOsA
