GOP Engineering Report #1
We are pleased to announce that the GOP token and its accompanying Uniswap pool have been deployed! What is dead may never die!!
GOP: 0x97ff946059f08a16f665ee2a0c673277fcd304b3
Pool on Uniswap: 0xf6efbab255bc9744d27c2cc137053dd7cb93d158
At present all trading is disabled. The official start of trading will begin in a few days. Please follow our Discord and Telegram groups for the exact opening time.
Now, I would like to give the floor to our programmer to explain some of the technical aspects of our monetary system, and to say a word or two concerning the delayed release (since we had previously expected that the pool would be created two days ago, on Saturday).
Hello, everyone. I am the programmer working for GOP. Lately there have been some technical questions which I thought I ought to address, but first, I think the community deserves an explanation regarding why we were not able to open Uniswap trading for the GOP token on Saturday.
The token was indeed deployed on Saturday, around an hour after our fundraising of 400 ETH was complete. However, we ran into two issues when connecting the token to Uniswap.
The first issue was that our code was designed to execute the function within Uniswap’s Router02 named addLiquidityETH(). This passage of code was written under the assumption that, if the corresponding Uniswap pool did not exist, then it would be automatically created. In fact, this assumption appears to be borne out by Uniswap’s own instruction-pages:
It is not my intention to blame Uniswap for the occurrence of this issue. It is entirely possible that I had misunderstood some of the nuances behind Uniswap’s various mechanisms and how they fit together.
The strangest thing was that the invocation of this function had succeeded when it was run in the simulator. Accordingly, after the invocation failed the first time when it was executing for real, I was led to repeat the operation twice more. Both of those attempts resulted in further failures. Since this was supposed to be a gas-consuming operation to begin with, I ended up wasting some money on the fees.
The second issue was that Uniswap rejected the hexadecimal format of the name of our token. The name “Game of Presidents” when converted to hexadecimal is:
0x47616d65206f6620507265736964656e7473
If we pad this value on the right to obtain 32 bytes, we get:
0x000000000000000000000000000047616d65206f6620507265736964656e7473
Here is what Solidity’s manual has to say:
As such, I expected, the correct format of the name to be:
0x0000000000000000000000000000000000000000000000000000000000000012
0x000000000000000000000000000047616d65206f6620507265736964656e7473
Strangely, Uniswap and, as I afterward discovered, a few other Ethereum-related tools, consider this format to be invalid, and the panels on their website (including the trading interface) respond by crashing. Conversely, MyEtherWallet and Etherscan allow this format. Thus, the formatting of the name was the last place I thought I would look for the origin of the problem. Fortunately, I had a mind to look through the JavaScript errors generated by their website for clues, and this led me to stumble upon the problem’s origin. The proper solution, as I came to discover, was to add an arbitrary 0x20 as the first machine-word, thereby turning the formulation into:
0x0000000000000000000000000000000000000000000000000000000000000020
0x0000000000000000000000000000000000000000000000000000000000000012
0x000000000000000000000000000047616d65206f6620507265736964656e7473
I am still not sure why exactly this works, but I am glad that the problem has been resolved. I also noticed that the names of several other tokens also contain the arbitrary 0x20 in their name.
The second part of this report is to respond to some of the questions and comments which were raised by our observant friends and followers:
Why does Etherscan not show the smart contract as verified?
The term “verified” when used in the context of Etherscan means to ensure that the low-level code of the smart contract matches up with the high-level code. Contrary to the connotation of the term, being “verified” provides no guarantee that a given smart contract is not a scam.
Since we wrote this smart contract directly in low-level code, the concept of being “verified” doesn’t even make sense in our case. Our code is inherently verified, since what you see on Etherscan (and on GitHub, with a few added comments, spacing, and punctuation) is exactly what the author wrote.
Writing low-level code directly violates the principles of the open-source movement.
Someone raised this point during a discussion, but sadly his assessment was mistaken. In reality, GNU, OSI, and other organizations within the FOSS community define “source code” as being whatever code was used by the author to create and revise the program in question. There are numerous open-source projects containing assembly-language, including the Linux kernel itself, a project which is considered the FOSS community’s flagship.
Nothing is gained by writing the smart contract in low-level code.
I am glad to point out that a few things are gained: fewer dependencies, the elimination of the need to trust Solidity’s codebase and its team, no more versioning problems stemming from Solidity’s numerous inconsistent releases, lower usage of gas during some critical routines, better proxying semantics (seeing that the use of proxies does not fit well with Solidity’s existing semantic model), better introspectional abilities, and the ability to define “vararg” functions are all decent reasons which come to mind. Maybe this is why there have been some Ethereum developers’ classes (a minority, admittedly) which have forgone Solidity altogether and encouraged students to directly study the EVM.
Also I would like to point out, the semantics of Ethereum’s low-level code are given a rigorous mathematical definition in the Yellow Paper by Gavin Wood. Nothing comparable exists for Solidity.
Two years ago, Ethereum’s community was even thinking of abandoning Solidity in favor of the emerging project known as Vyper (and the programmers of Uniswap originally jumped on this train) but sheer inertia combined with some of Vyper’s emergent deficiencies kept the Solidity language alive. A seasoned programmer would recognize this as being a repetition of the earlier dilemma between Python 2 and Python 3, something which I think is better altogether avoided.
Writing the language in low-level code impairs compatibility with ERC 20.
I am sorry to be blunt, but this is simply not true. ERC 20 (along with ERC 721 and ERC 1155) are examples of ABIs, not APIs. The difference between these two concepts is that an API contains language-specific definitions, whereas an ABI is meant to be language-agnostic, and is tailored instead to the requirements of the platform. From the start, the Ethereum Foundation committed itself to establishing ABIs in order to allow for maximal interoperability between a variety of different systems. Moreover, Solidity and other languages are compiled into low-level code anyways, so it isn’t humanely possible for any given system to go so far as to discriminate against low-level composition.
When you use low-level code to write a system, then that system will favor automated trading programs, to the detriment of human users.
This contention makes no sense. (Also, from the EVM’s point of view, all contracts are composed of low-level code.)
Not using Solidity violates the spirit of the Ethereum community.
Ethereum was originally launched with support for four smart-contract languages: Solidity, Serpent, LLL, and Mutan. The last was basically low-level code, very close to (but not identical to) the code of GOP. In fact, unlike Mutan, GOP’s code aligns 100% with Ethereum’s Yellow Paper. However, Serpent, LLL, and Mutan quickly died owing to lack of support, and the language intended to be the successor to both Serpent and Solidity, known as Vyper, has not become popular as its proponents had expected. If anything, we are doing our best to fulfil the community’s spirit.
Please keep an eye out for the announcement of the opening of Uniswap trading. We appreciate all of your support!
