Как мне сделать мой DAPP «защищенным от безмятежности»?

Когда наступит Serenity, сеть претерпит множество изменений, некоторые из которых могут иметь неожиданные последствия для существующих смарт-контрактов. Как я могу планировать, чтобы лучше всего подготовиться к использованию новых функций в Serenity и с меньшей вероятностью столкнуться с неожиданными ошибками и недостатками безопасности?

Ответы (1)

Это еще не точно, но:

  1. НЕ полагайтесь на очень подробные расчеты текущих затрат на газ. Предположим, что стоимость газа при вызове контрактов может увеличиться или уменьшиться на порядок в будущем хардфорке.
  2. При создании контрактов в сборке (т.е. не serpent, Solidity или LLL) НЕ используйте динамические операции JUMP/JUMPI (т.е. каждому JUMP/JUMPI должно непосредственно предшествовать значение PUSH, указывающее точную точку в коде для перехода)
  3. НЕ делайте ничего важного из-за опкода ТРУДНОСТЬ.
  4. НЕ полагайтесь на предположение, что время блока составляет от 12 до 20 секунд.
  5. НЕ думайте, что BLOCKHASH будут надежным источником случайности.
  6. НЕ предполагайте, что tx.origin будет продолжать использоваться или иметь смысл.
  7. НЕ предполагайте, что коды операций, отличные от 0xfe, останутся недействительными.

Не факт, что все эти шаги потребуются или что их будет достаточно, но это должно помочь вам в этом.

Итак, если tx.origin не имеет значения, будет ли msg.sender по-прежнему иметь значение?
Да, msg.sender останется значимым.
мы должны добавить: «НЕ ретранслировать, что 0x0 никогда не может быть msg.sender?» - или это идея стола?
Вполне вероятно, что мы сделаем точку входа отличной от 0x0, если мы увидим, что многие приложения используют 0x0 в качестве замены для «в этом слоте еще нет учетной записи» до такой степени, что использование 0x0 в качестве точки входа ставит под угрозу безопасность.
Почему блокхеши не являются надежным источником случайности?
@VitalikButerin Что является надежным источником инициатора цепочки вызовов в будущем, если не tx.origin?
@VitalikButerin, как мы можем предотвратить превращение контрактов в получателей значения, т. е. вредоносная резервная функция выдает шаблоны отправки, не требуя tx.origin == отправитель сообщения?
@VitalikButerin и еще один большой ... НЕ полагайтесь на номер блока или переменные, согласованные между контрактами. Прямо сейчас это в основном один глобальный блокчейн для всех контрактов, поэтому, пока ваша транзакция выполняется, она может полагаться на согласованность переменных в других сегментах. Но можем ли мы в сценарии сегментирования иметь условия гонки МЕЖДУ шардами, или он по-прежнему действует в полном ACID-режиме, как будто существует один гигантский блокчейн, и номера блоков будут монотонно увеличиваться во всех шардах, как и раньше? Будет ли это «выглядеть так же изнутри EVM?»
Как мне сделать мой DAPP «защищенным от безмятежности»?
СпросиСетьПолитика конфиденциальности1y, 0v