О я чисто по своей теме двигался и с китайцами болтал

Помню, у меня брал интервью в подкасте "про биткоин" Денис Хитов. Он им не брат?)

жесть))

А, эти ХитРовы, отбой

Не на столько на сколько может показаться) Вообще следующее поколение устройств позволит по 6-8 часов проводить в VR и нормально торговать

А эти чуваки поделили планету на участки и дали доступ к добавлению AR объектов на определенные места, блокчейн там конечно притянут за уши для хайпа, но по их заверением решает какие-то проблемы :)

Внятно мне так никто и не объяснил

Возможно кого-то это мероприятие заинтересует по аналитике и визуализации данных http://ue4daily.com/blog/nlvnla-2020.html

ты собираешься все сборища, где купил рекламное место сюда постить?

Реально, очень хорошее замечание! На заметку аудиторам. Всё дело в том, что init_code, от которого берется хэш при CREATE2 - это не код контракта, а код *генерации* кода контракта.
И при этой генерации ВНЕЗАПНО (sic!) разрешается использовать внешние данные. Хоть скачать байткод контракта из storage другого контракта.
Таким образом, в общем случае, одинаковый адрес не гарантирует одинаковую семантику контракта, поскольку возможно сделать универсальный загрузчик и добиться произвольного кода контракта на одном и том же адресе. А если код получившегося контракта содержит SELFDESTRUCT, и может самовыпиливаться из блокчейна, то тот же загрузчик способен загрузить любой другой произвольный код на его место. Поэтому, при проведении аудита, нужно не только проверять байткод на адресе и соответствующий ему верифицированный исходник, но и транзакцию, в реальности задеплоившую данный контракт.

Но если код генерации контракта не использует состояние блокчейна или данные текущей транзакции, то адрес, вычисляемый для CREATE2 является гарантией семантики контракта. И это может проверить аудитор. Так что для аудитируемости я бы делал CREATE2 только внутри смарт-контрактов-фабрик. Именно эти фабрики и нужно отдавать на аудит.

При этом, вместе с предвычисляемыми адресами выдавал бы клиентам некий witness (по факту - nonce), позволяющий убедиться, что на этот адрес может попасть ТОЛЬКО смарт-контракт, сгенерированный данной фабрикой, плюс в фабрике pure метод для проверки этого witness...

@khovratovich мож я переусложняю?

Адрес вычисляется как sha3( factoryAddress + initCode + nonce)[-40:] - т.е. зависит от кода и фабрики, т.е. только эта фабрика может создать с только таким кодом контракт по указанному адресу

Использование внешних данных — не баг, а фича, например можно сделать относительный таймлок, когда счетчик начинает работать с момента публикации контракта

Что как раз дает возможность создать канал без ограничения времени жизни

Все таки надо различать использование внешних данных и неизменность адреса в create2. Второе в сочетании с selfdestructом это огромная дыра в безопасности

В смысле, что я могу менять поведение контракта на адресе?
Чем это отличается от динамической линковки библиотеки?
Другое дело, что теперь нужно проверять создан ли ERC20 токен через фабрику, т.е. усложнилась задача по аудиту токена, но на то он и хардфорк

Андрей, обрати внимание из EIP 1014:

The init_code is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a 'constructor'.

Это по сути метапрограммирование

init_code может сгенерировать любой код