Response to Vitalik’s speech about ERC 23

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

Вот он 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 и в любой момент эти токены можно перевести из одного стандарта в другой.
Не важно какой формат человек выберет — всегда будет выбор стандартов. То есть это хорошо.

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

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.

It’s more complicated

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

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

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.

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

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store