Как можно рассчитать разницу во времени по block.number и чем она отличается от block.timestamp?

Я просматривал код, недавно сделанный некоторыми разработчиками, они используют block.number + числа для расчета разницы во времени. Например, если я хочу заблокировать средства на 6 месяцев или 180 дней, разработчики используют block.number + (некоторые рассчитанные числа 1296000 блоков) для расчета количества средств, которые нужно разблокировать.

Я хотел бы знать, как этот расчет работает с периодом времени. А почему бы вместо этого не использовать block.timestamp? Является ли block.number надежным?

Вот фрагмент кода. По сути, это хранилище, в котором токены хранятся 180 дней.

contract Vault is SafeMath {

    // flag to determine if address is for a real contract or not
    bool public isVault = false;

    Token token;
    address multisig;
    uint256 unlockedAtBlockNumber;
    // 1296000 blocks = 6 months * 30 days / month * 24 hours / day * 60 minutes / hour * 60 seconds / minute / 12 seconds per block
    //uint256 public constant numBlocksLocked = 1296000;
    // smaller lock for testing
    uint256 public constant numBlocksLocked = 12;

    /// @notice Constructor function sets the Lunyr Multisig address and
    /// total number of locked tokens to transfer
    function Vault(address _Multisig) internal {
        if (_Multisig == 0x0) throw;
        token = Token(msg.sender);
        multisig = _Multisig;
        isVault = true;
        unlockedAtBlockNumber = safeAdd(block.number, numBlocksLocked); // 180 days of blocks later
    }

    /// @notice Transfer locked tokens to multisig wallet
    function unlock() external {
        // Wait your turn!
        if (block.number < unlockedAtBlockNumber) throw;
        // Will fail if allocation (and therefore toTransfer) is 0.
        if (!token.transfer(multisig, token.balanceOf(this))) throw;
        // Otherwise ether are trapped here, we could disallow payable instead...
        if (!multisig.send(this.balance)) throw;
    }

    // disallow payment after unlock block
    function () payable {
        if (block.number >= unlockedAtBlockNumber) throw;
    }

}
Всем привет. Можете ли вы предоставить фрагмент кода, о котором вы спрашиваете?
Ричард, я обновил исходный пост примером кода. По сути, это хранилище, которое останавливает токены на 180 дней. Расчет производится путем расчета номера блока. Я хочу понять, как номер блока поможет рассчитать точные дни для остановки активов.

Ответы (2)

Я полагаю, что block.timestampэто дата/время настенных часов, когда был добыт блок. Номер блока, установленный в будущем на основе какого-либо другого блока, основан на оценке скорости майнинга блока. Например, среднее/целевое время блока на момент написания статьи составляет около ~17 с. Поэтому, если вы хотите установить время через 24 часа в будущем с помощью номера блока, вы можете использовать 24 * 60 * 60 / 17(количество секунд в сутках, деленное на количество секунд в блоке), чтобы примерно определить, какой номер блока будет добыт в это время. Обратите внимание, что для времен в середине и далеком будущем вам нужно будет принять во внимание ледниковый период: скорость генерации блоков будет замедляться по замыслу, чтобы стимулировать хард-форк для доказательства доли и, в Между тем, прибыльность майнинга существенно снижается (при выражении в eth) по мере продвижения ледникового периода.

Вот симулятор, чтобы получить представление о том, что происходит: https://gist.github.com/CJentzsch/c78768f9837afb8eef74 Обратите внимание, что скорость замедления была замедлена более поздним изменением протокола Ethereum, поэтому симулятор отсутствует. даты.

Большое спасибо за разъяснения. Это делает меня более ясным о расчете. Исходя из этого, у меня есть вопрос относительно расчета времени. Насколько безопасно использовать now() + (6 * 30 дней) для расчета периода времени? Я где-то читал без особых пояснений, что майнеры могут играть с датой и временем.
Я думаю, что алгоритм консенсуса позволяет майнерам возиться с датой в пределах небольшого диапазона, чтобы достичь консенсуса в отношении дрейфа часов; требуется консенсус для настенных часов, потому что он используется для расчета целевой сложности. Например, если на поиск блока ушло 5 секунд, а цель составляет 15 секунд, то сложность необходимо увеличить, чтобы сохранить время. Если бы консенсус не требовался, майнер мог бы установить время блока на какую-то отдаленную дату в будущем и «внедрить» несколько блоков, потому что в результате сложность была низкой.
И наоборот, кто-то с большой мощностью хеширования, пытающийся выдать отказ в обслуживании, может увеличить сложность в большей степени пропорционально своей мощности майнинга, создав впечатление , что блоки были «инстаминированы». Таким образом, если только сеть не была скомпрометирована/вредоносна (в этом случае могут возникнуть более серьезные проблемы, чем смарт-контракт), я думаю, что использование метки времени должно быть достаточно безопасным, но вам следует подождать, пока кто-то еще не взвесит; Я не являюсь экспертом в этом вопросе и пока не писал смарт-контрактов.

Отметку времени можно легко разыгрывать через короткие промежутки времени. Например, если блок n добывается в 13:30:00, майнер блока n+1 может поставить отметку времени следующего блока в 13:30:01, даже если на самом деле он не добыл его до 13:30:25.

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

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

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