![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
ethereum
Читаю сейчас книгу про то, как устроен Ethereum VM. Поразительная вещь - разрабатывая систему с нуля во втором десятилетии 21 века, люди умудрились сделать так, что там возможны и integer overflow/underflow, и uninitialized memory reference, и race conditions - в несколько извращённой форме, поскольку система по дизайну однопотоковая, но таки удалось!
Можно говорить, что проблема в компиляторах типа solidity, которые компилируют такой код без всяких проблем, а сама VM не виновата (от чего всё равно не легче, кстати), но хотя бы с overflows можно и на уровне VM бороться.
И, разумеется, все эти проблемы в реальных контрактах могут стоить владельцам реальных - ну т.е. воображаемых, но для них вполне реальных - денежных потерь. И уже стоили. Собственно, мега-форк экосистемы на Ethereum и Ethereum Classic произошёл именно из-за одного такого бага. Там, кажется, попятили виртуальных печенюшек на сумму в 50 млн. Конечно, вряд-ли все 50 млн можно будет обналичить, да и не факт, что вообще что-то можно будет, но сама по себе история впечатляет.
Такое впечатление, что опыт последних 30 лет никого ничему не научил. Т.е. я понимаю, что сделать систему без багов невозможно, все дела, но когда речь идёт о граблях, на которые наступают уже много десятилетий, может можно хотя бы не раскладывать их прямо на дороге?
Можно говорить, что проблема в компиляторах типа solidity, которые компилируют такой код без всяких проблем, а сама VM не виновата (от чего всё равно не легче, кстати), но хотя бы с overflows можно и на уровне VM бороться.
И, разумеется, все эти проблемы в реальных контрактах могут стоить владельцам реальных - ну т.е. воображаемых, но для них вполне реальных - денежных потерь. И уже стоили. Собственно, мега-форк экосистемы на Ethereum и Ethereum Classic произошёл именно из-за одного такого бага. Там, кажется, попятили виртуальных печенюшек на сумму в 50 млн. Конечно, вряд-ли все 50 млн можно будет обналичить, да и не факт, что вообще что-то можно будет, но сама по себе история впечатляет.
Такое впечатление, что опыт последних 30 лет никого ничему не научил. Т.е. я понимаю, что сделать систему без багов невозможно, все дела, но когда речь идёт о граблях, на которые наступают уже много десятилетий, может можно хотя бы не раскладывать их прямо на дороге?
no subject
Де факто системы с гарантиями стали делать только недавно. См. го и раст.
Если открыть C++ там все так плохо, что той Солидити срать и срать.
И комитет по C++ прогоняет такую пургу, что стыдно.
Из всех чуваков по VM которых я знаю норм мозги есть только у авторов KVM и Линуса Торвальдса.
Все остальное - ну такое.
no subject
Это бессмысленное утверждение, т.к. цель и смысл C/C++ состоят в возможности написания максимально производительного софта на portable языке высокого уровня.
Это как сказать "в гоночной машине все так плохо - в столб на ней врежешься мало не покажется".
no subject
Я про тонкости стандарта, написанные астронавтами, которые в жизни не разрабатывали ничего.
no subject
no subject
no subject
no subject
На петоне попеши, там за тебя даже форматирование язык решает!
Пороха не нюхали!!!
Re:См. го и раст.
На моё имхо, язык не только не заменит межушный нервный узел, но и отнюдь наоборот- чем больше будут уповать на то, что вот теперь-то на (D,F, Go...) будет по-другому и всё станет хорошо, тем глубже будет "хотели как лучше, а вышло как всегда" (с).
Re: См. го и раст.
Re: См. го и раст.
Re: См. го и раст.
Re: См. го и раст.
Проект на сиквеле без тестов почти. На питоне как обычно 50% кода тесты. Питонский после этого ломался постоянно (при изменения ессно). А сиквел работал как по рельсам. И кода в нем было в 5 раз меньше.
Т.е. сиквел и легче и более защищен от идиотов.
Или можно смотреть с другой стороны: жабаскрипт на порядок сложнее сиквела, но в среднем на нем пишут такие макаки, что туши свет.
Re: См. го и раст.
Re: См. го и раст.
Re: См. го и раст.
made my day
no subject
no subject