Боря программирует

Каждый раз, когда взаимодействую с миром блокчейна, меня поражает смелость людей, которые пишут для них смарт-контракты. Если в контракте есть хотя бы несколько сотен строк, то почти наверняка в нем будут баги. Скорее всего какие-то не очень важные, которые вряд ли приведут к потере всех денег. Но что если там тысяча строк? А если несколько тысяч? Чисто статистически там будут баги, сколько бы вы не написали тестов.

Даже в самых важных и хорошо протестированных программах постоянно находят уязвимости. И обычно надежда на то, что их найдут добрые люди, расскажут разработчикам, и они успеют выпустить фикс до того, как о проблеме узнает кто-то другой. В случае же со смарт-контрактами довольно часто нет возможности их обновить. И в итоге, даже если вы знаете, что баг есть, возможности его исправить уже нет.

На выходных вот прошел контест от Telegram по поиску багов в их контракте для покупки красивых имен (я даже что-то выиграл). И несмотря на то, что разработчики Telegram явно имеют опыт написания надежного кода, какие-то баги в контракте все равно нашли.

А еще иногда кажется, что когда дизайнили TON, никто не пытался минимизировать шанс того, что в смарт-контрактах эти баги будут.

Например, в TON есть особые bounced сообщения, которые большинство контрактов хотят просто игнорировать. Но нужно сделать это в явном виде и легко забыть написать код, который будет это делать. Почему нельзя было сделать поведение по умолчанию другим? Или заставить разработчиков писать два обработчика сообщений?

Еще, например, там нет автоматического подсчета текущего количества денег (который учитывает сообщения, которые будут отправлены). После этого в большом количестве контрактов разработчики должны по всему коду протаскивать переменную my_balance и не забывать ее правильно обновлять (что сложно).

А еще все функции по умолчанию считаются чистыми, и, если у них нет возвращаемого значения, просто игнорируются. Например, вы можете написать функцию, которая проверяет валидность данных, забыть добавить модификатор impure, и никаких проверок не будет происходить. Почему нельзя было сделать impure значением по умолчанию?

Если вы дизайните какой-то API, и хотите сделать какое-то неочевидное/ломающее поведение по умолчанию, лучше вместо этого заставьте пользователя явно сделать выбор самому.

❤14👍2

www.tgoop.com/bminaiev_blog/21

1.65K viewsedited  Oct 26, 2022 at 19:17

Каждый раз, когда взаимодействую с миром блокчейна, меня поражает смелость людей, которые пишут для них смарт-контракты. Если в контракте есть хотя бы несколько сотен строк, то почти наверняка в нем будут баги. Скорее всего какие-то не очень важные, которые вряд ли приведут к потере всех денег. Но что если там тысяча строк? А если несколько тысяч? Чисто статистически там будут баги, сколько бы вы не написали тестов.

Даже в самых важных и хорошо протестированных программах постоянно находят уязвимости. И обычно надежда на то, что их найдут добрые люди, расскажут разработчикам, и они успеют выпустить фикс до того, как о проблеме узнает кто-то другой. В случае же со смарт-контрактами довольно часто нет возможности их обновить. И в итоге, даже если вы знаете, что баг есть, возможности его исправить уже нет.

На выходных вот прошел контест от Telegram по поиску багов в их контракте для покупки красивых имен (я даже что-то выиграл). И несмотря на то, что разработчики Telegram явно имеют опыт написания надежного кода, какие-то баги в контракте все равно нашли.

А еще иногда кажется, что когда дизайнили TON, никто не пытался минимизировать шанс того, что в смарт-контрактах эти баги будут.

Например, в TON есть особые bounced сообщения, которые большинство контрактов хотят просто игнорировать. Но нужно сделать это в явном виде и легко забыть написать код, который будет это делать. Почему нельзя было сделать поведение по умолчанию другим? Или заставить разработчиков писать два обработчика сообщений?

Еще, например, там нет автоматического подсчета текущего количества денег (который учитывает сообщения, которые будут отправлены). После этого в большом количестве контрактов разработчики должны по всему коду протаскивать переменную my_balance и не забывать ее правильно обновлять (что сложно).

А еще все функции по умолчанию считаются чистыми, и, если у них нет возвращаемого значения, просто игнорируются. Например, вы можете написать функцию, которая проверяет валидность данных, забыть добавить модификатор impure, и никаких проверок не будет происходить. Почему нельзя было сделать impure значением по умолчанию?

Если вы дизайните какой-то API, и хотите сделать какое-то неочевидное/ломающее поведение по умолчанию, лучше вместо этого заставьте пользователя явно сделать выбор самому.

BY Боря программирует