ethereum

[stas]

Читаю сейчас книгу про то, как устроен Ethereum VM. Поразительная вещь - разрабатывая систему с нуля во втором десятилетии 21 века, люди умудрились сделать так, что там возможны и integer overflow/underflow, и uninitialized memory reference, и race conditions - в несколько извращённой форме, поскольку система по дизайну однопотоковая, но таки удалось!
Можно говорить, что проблема в компиляторах типа solidity, которые компилируют такой код без всяких проблем, а сама VM не виновата (от чего всё равно не легче, кстати), но хотя бы с overflows можно и на уровне VM бороться.

И, разумеется, все эти проблемы в реальных контрактах могут стоить владельцам реальных - ну т.е. воображаемых, но для них вполне реальных - денежных потерь. И уже стоили. Собственно, мега-форк экосистемы на Ethereum и Ethereum Classic произошёл именно из-за одного такого бага. Там, кажется, попятили виртуальных печенюшек на сумму в 50 млн. Конечно, вряд-ли все 50 млн можно будет обналичить, да и не факт, что вообще что-то можно будет, но сама по себе история впечатляет.

Такое впечатление, что опыт последних 30 лет никого ничему не научил. Т.е. я понимаю, что сделать систему без багов невозможно, все дела, но когда речь идёт о граблях, на которые наступают уже много десятилетий, может можно хотя бы не раскладывать их прямо на дороге?

Comments

[lsh123]

No surprises. It was built by 18-20 year old kid who won tons of CS competitions but who never worked in a real software engineering company. I see code like this all the time from new grads in the first 12-18 months ;)

[lxe]

The word is "hipsters".

[stas]

Solidity wasn't written by Vitalik. And I am ready to give more pass to him (he basically was implementing the CPU, thinking about application security is not a common concern about CPU designers, see Intel) but designer of Solidity has no excuses whatsoever.

[juan_gandhi]

Ну вот странно, блин.
Может быть сейчас уже, когда чуть что и раст в руках, вещи как-то поулучшатся. Бутерину, конечно, не до надежности было, да и...

[stas]

Ну Бутерин не один это писал. Я понимаю, что подростку кажется, что всё, что существовало до него, не имеет значения, и история мира заново началась с него. Но неужели некому было рассказать о том, что на все эти грабли уже наступали?

[juan_gandhi]

А кто их будет слушать? Вот меня на работе желающих слушать почти нету. Ну чо там, type safety, она же не фиксит никакой баг. Вот будет баг...

Ох, как все это достало, конечно.

[stas]

Ладно type safety. Но элементарно не вставлять в язык херню типа "если ты забыл инициализировать переменную, то она будет указывать на какой-то левый участок памяти, и кто хочет сможет туда писать" можно было хоть?

[cjelli]

https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/

[e2pii1]

Что хорошо для отсеивания тупых необязательно лучший выбор для финансового софта (если не требуется высочайшей производительности)

[cjelli]

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

[http://users.livejournal.com/sorcerer-/]

Качество дискуссии так себе, особенно позабавил мап-редьюс.

[juan_gandhi]

Да, могли бы. Я вообще не понимаю такой херни как "неинициализированная переменная".

[http://users.livejournal.com/sorcerer-/]

Для этого надо хорошо разбираться в перформансе.

[http://users.livejournal.com/sorcerer-/]

Потому, что везде хуяк-хуяк и в продакшен.
Де факто системы с гарантиями стали делать только недавно. См. го и раст.
Если открыть C++ там все так плохо, что той Солидити срать и срать.
И комитет по C++ прогоняет такую пургу, что стыдно.
Из всех чуваков по VM которых я знаю норм мозги есть только у авторов KVM и Линуса Торвальдса.
Все остальное - ну такое.

[e2pii1]

> Если открыть C++ там все так плохо, что той Солидити срать и срать.

Это бессмысленное утверждение, т.к. цель и смысл C/C++ состоят в возможности написания максимально производительного софта на portable языке высокого уровня.

Это как сказать "в гоночной машине все так плохо - в столб на ней врежешься мало не покажется".

[http://users.livejournal.com/sorcerer-/]

Это очень поверхностное понимание.
Я про тонкости стандарта, написанные астронавтами, которые в жизни не разрабатывали ничего.

[arifg]

Знаете, мне тут по долгу службы пришлось окунуться в эппловский Свифт, где все это решено, и обернуто бантиками, так я жду-недождусь, когда, наконец, этот проект закончится и мне удастся вернуться к С/С++ и Винде, где можно наступить на мину, особенно когда пишешь код для ядра, но зато не чувствуешь себя как в концлагере и где все зависит только от тебя, а не от дяди и его понимания "правильного кода". Может, я такой олдтаймер и анархист, но вот.

[stas]

Я думаю, существует золотая середина между эпловским B&D и раскладыванием неожиданных граблей на всех дорожках. Если бы речь шла о C, я б не удивлялся - ну C и C, все знают, чего ожидать, не можешь справиться с жарой - вали с кухни. Но тут специально выдумали специальный язык, и на тебе - та же фигня.

[arifg]

А было ведь такое: Visual Basic 6. Прибили гады... Эх, где те золотые времена...

[http://users.livejournal.com/sorcerer-/]

> все зависит только от тебя, а не от дяди и его понимания "правильного кода"

На петоне попеши, там за тебя даже форматирование язык решает!
Пороха не нюхали!!!

Re:См. го и раст.

[yarpenzigrin]

Да-да. Когда-то что-то такое я слышал про джаву.
На моё имхо, язык не только не заменит межушный нервный узел, но и отнюдь наоборот- чем больше будут уповать на то, что вот теперь-то на (D,F, Go...) будет по-другому и всё станет хорошо, тем глубже будет "хотели как лучше, а вышло как всегда" (с).

Re: См. го и раст.

[stas]

В этом смысле я всегда вспоминаю, что SQL был разработан, как естественный язык запросов, на котором каждый лох без всякого опыта и образования может написать запрос к базе и оно всё тут же выдаст без проблем. Вспоминаю и безудержно ржу.

Re: См. го и раст.

[http://users.livejournal.com/sorcerer-/]

Есть очень много менеджеров которые вполне хорошо пишут на sql. И вообще это действительно самый лёгкий и понятный язык из всех.

Re: См. го и раст.

[stas]

Менеджеры тоже умные бывают :) Насчёт легкости SQL я бы поспорил, особенно когда речь идёт о хорошем наборе джойнов, со всякими аггрегатами, окнами и иерархиями.

Re: См. го и раст.

[http://users.livejournal.com/sorcerer-/]

Ну. Я знаю точно об одном проекте по анализу сейлзов где два чувака делали примерно одно и то же. На питоне и на сиквеле.
Проект на сиквеле без тестов почти. На питоне как обычно 50% кода тесты. Питонский после этого ломался постоянно (при изменения ессно). А сиквел работал как по рельсам. И кода в нем было в 5 раз меньше.
Т.е. сиквел и легче и более защищен от идиотов.

Или можно смотреть с другой стороны: жабаскрипт на порядок сложнее сиквела, но в среднем на нем пишут такие макаки, что туши свет.

Re: См. го и раст.

[toshick]

как человек, когда-то написавший проект в 50 000 строк кода на MS TransactSQL, я абсолютно этому не удивлен

Re: См. го и раст.

[e2pii1]

"Израильский SQL-сервер всегда отвечает запросом на запрос"

Re: См. го и раст.

[toshick]

а-а-а !

made my day

[stas]

В C++ так задумано, ну и плюс это ж всё-таки C, хоть и с плюсами. А ему уже 50 лет скоро, тут обижаться не на что. А в 2010-х можно уже использовать опыт поколений.

[http://users.livejournal.com/sorcerer-/]

C++ 2017 - это тоже война и немцы.

[dmitryvlasov]

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

[lexxnech]

Какие могут быть баги в системе, в которой "code is law"? Это не система упала из-за ошибки, это у пользователей ошибочное мнение, что она должна была продолжать работать, а система упала вполне штатно.
И основной конфликт форка был из-за того, что идейные пуристы никакого нарушения не признали - если система позволила увести деньги, то значит это была совершенно законная сделка.

[stas]

Выясняется, code is law никому на самом деле не нужно. Сюрприз!

[lexxnech]

Ну, некоторым был нужен, так что драма во время форка была внушительная. Получился весьма занятный эксперимент, когда крупная криптовалюта практически идеально разделилась на две независимые, одна из которых для "потребителей", видящих в ней финансовый инструмент, а вторая для "криптовалютных энтузиастов" которым важнее всего соответствие изначально объявленным криптовалютным ценностям и которые составляли изначальный костяк сообщества. Что характерно, потребительская сейчас стоит в ~30 раз дороже энтузиастской.
Но в целом, это было очень самоуверенно, делать ключевым пунктом идеологии проекта то, что если поведение кода не соответствует спецификации, то ошибка в ней, а не в коде.

[stas]

Энтузиастам, на самом деле, тоже это не нужно, просто они решили проявить стоицизм. Подозреваю, что у большинства энтузиастов не было серьёзных денег, вложенных в DAO... Хотя в принципе идея, что баги влекут денежную ответственность, интересная, но я бы лично на неё не подписался, как программист со стажем. Особенно на платформе, где раскладывать ржавые грабли на дороге считается нормой.

[none_smilodon]

У Эфира есть такое количество непреодолимых катастрофических проблем (тот же рост блокчейна), что Виталик и компания пребывают в состоянии экзистенциального ужаса, на фоне которого все остальное мелкие баги.

[prakapovich]

что за книга?

[stas]

https://www.amazon.com/Mastering-Ethereum-Building-Smart-Contracts/dp/1491971940