Response to Vitalik’s speech regarding ERC-223

You can watch the original Blockchain Developers Meetup here:

Vitaliks’ original speech about ERC-223 in Russian:

Я сейчас на самом деле ещё не посмотрел. Я могу сейчас очень быстро посмотреть.

Вот он ERC23. Давай-ка посмотрим. Конечно больше сложности. Это то что `transferToContract` и `transferToAddress`. А понятно, то есть это внутренняя функция. Вот это я думаю не очень умная мысль, потому что наш долгосрочный план через EIP86 мы хотим что бы каждый аккаунт стал контрактом, то есть мы хотим, чтобы концепция неконтрактового аккаунта не существовала и мы любим такую идеологию Эфириума: если есть чистая общая система, то лучше если все описано через код, то лучше пусть всё и будет описано через код. [Я понимаю это так: “Если есть вещи, работа которых одинакова с идеологической точки зрения, то и коды, описывающие их работу, должны иметь одинаковую логику.”] Это конечно не очень будет хорошо работать в долгосрочной перспективе, но сейчас может иметь преимущество.

Какие у них тут, посмотрим, аргументы. `transferToAddress`, но ещё есть `data` field, а понятно, то есть они хотят чтобы можно было передать токены контракту и одновременно передать какие-то данные, потом контракт, который работает с токенами… Сделать так что бы транзакции токенами работали так же как и транзакции эфира. Я понимаю, что они пробуют делать. Я думаю, проблема такая: если сейчас в иных случаях нужно сделать функцию, которая принимает эфир, то есть ты, например, хочешь купить какие-то токены, REP к примеру, децентрализованная биржа в общем, в ней есть функция, в которую нужно как часть функции подать эфир. Сейчас если подать эфир, то можно вызвать функцию одним call’ом, но если ты хочешь платить за что-либо через ERC20 токен, то нужно сначала сделать одну функцию с `approve`, потом ещё одну функцию `transferFrom`, которая возьмёт токен, а потом уже внутри контракта будет ещё третий вызов функции. То есть проблема такого механизма в том, что он тратит много газа, он не совсем удобный.

Они хотят сделать это аналогично с эфиром — транзакция токена передаёт данные, которыми закодирован вызов контракта, как `data` транзакции эфира.
Потом он пробует вызвать `tokenFallback`. Проблема такого подхода в том что он не очень хорошо подходит с существующим ABI.
Получается они пробуют сделать свой ABI, в котором есть функция `tokenFallback`, один из аргументов `tokenFallback` будет msg.sender, и получается что чтобы найти кто sender нужно не использовать опкод `sender`, а взять этот вот кусок памяти. Внутри `tokenFallback` будет ещё `data` и это будет ещё одна внутренняя функция.
Я понимаю как они хотят понизить сложность, но я боюсь что такой подход наоборот ещё больше увеличит сложность.
Инстинктивно мне пока всё равно ERC20 больше нравится, но я понимаю почему людям ERC23 тоже нравится.

Преимущество в том что если есть один токен ERC20, есть ещё один токен ERC23, который можно обменивать через контракт в токен ERC20, получается такой ERC23 токен, подкреплённый токеном ERC20, то люди могут использовать оба стандарта параллельно, кому нравится — те пользуются ERC20, кому ERC23 — те пользуются ERC23 и в любой момент эти токены можно перевести из одного стандарта в другой.
Не важно какой формат человек выберет — всегда будет выбор стандартов. То есть это хорошо.

Это всё что я пока хочу сказать об этом.

English variant:

I have not yet watched. I can watch now.

It’s more complicated that there are `transferToContract` and `transferToAddress`. It’s internal functions. This is not a very clever idea, i think because of we are planning to make each account a contract (in EIP86). We don’t want no-contract account conception to exist. We like the following ideology in Ethereum: “If there is a total system, then let it be written in the code”. [I think it means: “If there are ideologically similar things then their code should have similar logic of work.”]
This [ERC23] will not work very well in long term but now it can have advantages.

Let’s look through their arguments. `transferToAddress` and `data` field means they want to attach data to token transactions. Let token transactions work similar to Ether transactions. I understand what they are trying to do.
I think the problem is you can execute payable function and send Ether with a single call. But if you want to pay something with ERC20 token you should call `approve` first, then call a function that will call a third function `transferFrom` to take your tokens. Problems of this mechanism [ERC20 `approve`+ `transferFrom`] are it’s spending a lot of gas and it’s not convenient.

They want it to be the same to Ether transactions. Token transaction will contain `data` field. `data` is encoded call of contract like `data` in Ether transactions.
Then it’s trying to call `tokenFallback`. The problem of this method is that this is not matching current ABI.
They are trying to make their own ABI with `tokenFallback` function. One of `tokenFallback` args will be `msg.sender` so we cant use `sender` opcode to get sender. We need to access this variable in memory [`_from` arg of `tokenFallback` function]. There will be `data` inside `tokenFallback` and it will be the next function call.

I understand how they try to reduce complexity, but I’m afraid that this will increase complexity on the contrary.
I still like ERC20 more but I understand why people do like ERC23.

There is an advantage that people can use both standards. For example it is possible to create ERC23 token backed by ERC20 token and it will be possible to exchange each token to another. There will be a choice of standard you would like. It’s good.

That’s all I want to say now.

I want to provide my response to this overview.

I have designed ERC23 to solve a number of problems I found important.
This problems are:

1. Users can lose their tokens in contracts and it often happens.
2. There is no way to handle incoming token transactions.
3. I like Ethereum’s ideology “similar things should have similar logic of code” but ERC20 transactions are not similar to Ether transactions.
4. approve function is potentially vulnerable in current implementation. Read more here.

Let me explain each point more detailed. I have already wrote an article about ERC20 tokens that are already lost and will never be accessible. https://www.reddit.com/r/ethereum/comments/60ql37/attention_be_careful_using_ethereum_tokens/

The user does not need to know about the internal logic of the token contract in order to use tokens. The existing method of depositing ERC20 tokens to contracts or transferring ERC20 tokens is too confusing for regular users.

Calling a handler function is the standard event handling method in programming. Developers may be confused by the fact that there is no way to handle incoming ERC-20 token transactions.

Ether transactions and token transactions are similar things. They are “transactions”.

Ether transaction:

1. Transfers value.
2. Could be handled.
3. Can execute functions in contract.
4. Could be rejected if something goes wrong or executed function is not accepting payments.
5. Can contain hex messages.
6. There is no difference between “send transaction into contract” and “send transaction into wallet address” from users point of view.

I’m trying to create a token that will behave in similar way.

Let me comment some moments.

It’s more complicated

I don’t found it more complicated. If you found my proposal more complicated for contract developers, then I found this increase in complexity a reasonable price, which should be paid for preventing accidental loss of tokens in the entire future. This will also make token usage less complicated for regular users.

We like the following ideology in Ethereum: “If there is a total system, then let it be written in the code”.

Exactly. It was one of my goals of developing ERC23 too. It is third point in list of problems I marked above.

This [ERC223] will not work very well in long term but now it can have advantages.

I like the idea of smart-contract wallets. I am ready to implement any idea that would be suggested.

Anyways, smart-contract wallets will handle incoming Ether transactions. I think that incoming token transactions should be handled in similar way.

From technical point of view:

1. transferToAddress can become rudimentary.
2. transferToContract will be executed every time someone is trying to send transaction to a wallet-contract that contains code.
3. Wallet-contracts should implement ReceiverInterface to receive tokens.
4. It may be a good idea to implement it by default like empty fallback function() payable { } that will allow to receive Ether.

The main problem is that tokens can get stuck inside the contract. There will be no problem with tokens if they are accidentally sent to the wallet-contract. The owner of wallet-contract can always send tokens.

tokenFallback needs to be executed even inside wallet-contract.

The problem of this method is that this is not matching current ABI.
They are trying to make their own ABI with `tokenFallback` function. One of `tokenFallback` args will be `msg.sender` so we cant use `sender` opcode to get sender. We need to access this variable in memory.

Receiver must implement ReceiverInterface to receive tokens.
While handling incoming tokens inside tokenFallback(_from, _amount, _data) function we can access sender of tokens by _from variable. msg.sender will be token contract address so handler will know what tokens are sent.

If someone can find this not convenient, then this extension can be implemented:

struct tkn {

address sender;

uint value;

bytes data;

}

function tokenFallback(_from,_amount,_data)

{

tkn.sender=_from; tkn.value=_amount; tkn.data=_data;

}

Sender of transaction (token contract) will be accessible as msg.sender and variables of token transaction (token sender, tokens amount sent and data of token transaction) will be accessible as tkn.sender / tkn.value / tkn.data .

I understand how they try to reduce complexity, but I’m afraid that this will increase complexity

I do not think it will be an increase in complexity, because I used the well-known method of event handling in programming.