@gavofyork Кстати, персистивный кеш для wasm модулей есть уже в wasmer. Им удалось ускорить таким образом запуск в 100 раз:
https://medium.com/wasmer/running-webassembly-100x-faster-%EF%B8%8F-a8237e9a372d

ого

Говорю же теоретики из Эфириума страшно тормозят развитие платформы, то о чем о ни дисскусируют сейчас в твиттере и на конференциях уже давно работает для EOS.io, Near Protocol, и даже для браузеров и прошло проверку боем =)

Для хеша они кстати сейчас используют blake2bp, что дает хороший баланс по производительности и надежности (защиты от коллизионной атаки)

При чем ты понимаешь, что бы осуществить атаку в этом направлениии тебе нужно найти две бинарника у которых есть коллизия (один из них должен делать что то плохое, второй для маскировки), оба должны потом еще пройти валидацию=) Я не знаю если во вселенной такой байткод вообще) Но если ребят из Эфириума сильно параноит, но не вопрос - просто вводим еще одну хеш сумму скажем для sha256 =)

трудно не согласиться

С колокольни биткоин максималистов эфириум деплоит абгрейды с безрассудной скоростью

Не вижу в этом проблемы

суть же не в количестве

В конце концов, если вдруг это станет проблемой на уровне архитектуры, то просто вводится таймаут и человек не может провести апдейт скажем чаще чем генерация/валидация двух трех блоков

Кстати да, вместо вычисления хэша над бинарником можно сделать AST merklization, или даже использовать компиляцию/сериаизацию wasm как некое подобие докозательства работы

это вообще огонь

кстати. Ка на счет топить за https://twitter.com/ensdomains в качестве замены DNS для интернета?

олдфаги помнят namecoin

это лучше даже

Это все абсолютно, не имеет смысла, так как провайдеры умеют проделывать вот такое:
https://habr.com/ru/post/320700/

А этот дед конечно прикольный, но консерватор тот еще)

а вот это не помогает?

https://en.m.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

вот ещё из каментов:


OpenVPN умеет посылать настройки DNS клиентам. Таким образом, если поднять свой DNS-сервер (тот же bind или dnsmasq), и настроить его на ответы внутрь VPN, то можно будет пользоваться.

У меня настройка такая:
— внутрь VPN смотрят bind, lighttpd и privoxy
— VPN не прописывается как шлюз по умолчанию.
— клиенты цепляются к VPN всегда, и настроены использовать bind как первичный DNS-сервер, и гуглоднс — как вторичный.
— браузеры настроены на использование proxy autoconfig file, который отдаётся lighttpd на сервере.
— proxy autoconfig файл генерируется по крону и направляет запросы для сайтов из черного списка на privoxy (черный список беру с antizapret). Остальные запросы идут напрямую.

Таким образом, VPN используется выборочно, для DNS-запросов и для загрузки сайтов из чёрного списка, что очень удобно.
Минус такого подхода — необходимость полноценного доступа к VPN серверу (VPN-провайдеры не подойдут), и наличие знаний для настройки всего этого хозяйства.

В качестве апгрейда я накатил openvpn клиент на роутер, открыв всем устройствам в домашней сети доступ в VPN, и настроив dnsmasq на роутере на работу с bind. Так что любое устройство с минимальными настройками может пользоваться туннелем.