Прогноз изменения переменной контракта

Я считаю, что это очень простой вопрос, но я не смог найти прямого ответа в документации или Google. Я новичок в Solidity/Ethereum и, возможно, я еще не до конца понимаю некоторые основные концепции.

Итак, давайте используем простой код, подобный этому

contract StrangeToken {

  uint256 private repurchasePrice;   
  mapping(address => uint256) balances;

  function setPrice(uint256 price) {   
   repurchasePrice = price;   
  }  
}

Любой может вызвать setPrice()функцию для установки repurchasePriceпеременной. Предположим, что есть тысячи пользователей и setPrice()звонят каждую минуту или даже чаще, а значение устанавливается в какое-то случайное число.

Возникает вопрос: насколько сложно предсказать и/или повлиять на значение repurchasePrice для ближайших будущих/ближайших блоков.

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

Спасибо!

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

Ответы (2)

Я не уверен, что полностью понял ваш вопрос, но я думаю, что понял его суть.

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

Каждый может видеть кандидатов как ожидающие транзакции (с несколько разными представлениями упорядочения из-за сетевой задержки).

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

pragma solidity ^0.4.13;

contract NotSoSecret {

    bytes32 public secretHash;

    // put some money in with a hashed secret

    function deposit(bytes32 _secretHash) public payable returns(bool success) {
        secretHash = _secretHash;
        return true;
    }

    // if you know the magic word, you get the pot

    function claim(bytes32 password) public returns(bool success) {
        if(sha3(password) == secretHash) {
            msg.sender.transfer(this.balance);
            return true;
        }
        return false;

    }
}

Это выглядит так, как будто это должно работать, но это не так. depositпринимает средства и хэш. Похоже, чтобы получить добычу, нужно знать пароль.

На самом деле произойдет то, что кто-то, кто знает, passwordотправит транзакцию claim, и эта неподтвержденная транзакция будет передана в сеть (об этом узнают майнеры и полные узлы).

Это будет стимулировать гонку, потому что все увидят пароль. Таким образом, когда злоумышленник использует эти знания для совершения собственной транзакции (чтобы получить вознаграждение для себя), он будет иметь (примерно) 50/50 шансов на успех. Зачем останавливаться на одной попытке? Контракт может быть засыпан претензиями, как только секрет будет раскрыт.

Надеюсь, поможет.

Возникает вопрос: насколько сложно предсказать и/или повлиять на значение repurchasePrice для ближайших будущих/ближайших блоков.

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

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

С точки зрения майнера, основная задача состоит в том, чтобы найти действительный хэш в зависимости от сложности времени майнинга. Если он попытался передать блок с недействительными транзакциями (скажем, атаковать ваш контракт), когда он будет проверен, поскольку транзакция недействительна, добытый им блок будет отклонен.

Таким образом, способ атаки на ваш контракт — отправить действительную транзакцию, но использовать лазейку в вашем контракте. Итак, что вы можете сделать, так это следовать передовым методам разработки безопасных контрактов. Вы можете сослаться на ссылки: документы Solity и этот пост , посвященный безопасной солидности .

Атака DOA — хороший пример того, почему вы должны писать безопасные коды надежности, не позволяя другим использовать ваш контракт в своих интересах.