Comments 8
Шаг 2. Генерация публичного ключа.
На основании приватного ключа при помощи алгоритма ECDSA (Elliptic Curve Digital Signature Algorithm) генерируется публичный ключ.
Разве [публичный ключ] получается не путем умножения [приватного ключа] на [генератор эллиптической кривой]? При чём тут тогда ECDSA?
Насколько мне известно, генерация приватного и публичного ключа для ECDSA определена в самом стандарте ECDSA
Про "служебные адреса" не совсем так. Их не существует на самом деле, это кто-то из пользователей решил что "а давайте будем использовать 0xdead" для сжигания. Это мог быть любой другой набор цифр, так же как многие используют 0x0000 для этого. Можете отправлять на 0x0001 и т.д., будет тот-же эффект. Это просто очевидно несуществующий адрес.
А для создания контрактов не использует адрес вообще, т.к. это не 0x0000 а вообще ничего (null).
Данные адреса были специально выбраны для целей сжигания, так как подобрать приватные ключи к ним невозможно (или крайне маловероятно). На адресах присутствует баланс. Это вполне реальные адреса и они существуют в блокчейне, с той лишь разницей, что к ним ещё никто не подобрал приватный ключ. Если была договорённость использовать эти адреса для сжигания, то вполне уместно сказать, что они служат определённой цели, то есть являются служебными (до тех пор пока ключ не подобрали).
Насколько я понимаю из Ethereum Yellow Paper, в транзакции на создание контракта вы можете указать и null в поле to. EVM интерпретирует null как пустую RLP последовательность или последовательность из нулей: Section 4.2 : The Transaction Можно указать и сразу одни нули в поле to.
Gavin Wood прямо указал адрес 0x0 в адресате транзакции на создание контракта. В документации Ethereum указали null в качестве адресата. Так что не принципиально, EVM поймёт, что это создание контракта в обоих случаях.
Я к тому что договоренность не официальная и не обязательная. Не было процедуры "специального выбора", просто многим людям пришло в голову очевидная вещь что для простого адреса без ключа логично использовать нули. Можно использовать любой другой адрес к которому вы считаете ни у кого нет ключа.
А адреса все реальные. Их 2^160 и они всегда существуют и существовали до изобретения Ethereum. Наличие или отсутствие баланса ничего не означает.
Если в транзакции указать одни нули то транзакция уйдет на адрес с нулями. Чтобы создать контракт нужно именно null. Некоторые интерпретации RLP пишут на экране 0x0 вместо null видимо подразумевая байты нулевой длинны, но это в любом случае не 0x0000000000000000000000000000000000000000 (адрес из 20 байт).
Благодарю за подсказку, спасибо! Действительно, был не прав насчёт нулевого адреса при создании контракта. Сейчас вручную создал два контракта один с 0x0000000000000000000000000000000000000000 в качестве адреса получателя, другой без поля to (то есть null). В первом случае транзакция просто ушла на нулевой адрес и контракт не был создан, во втором случае контракт создался.
Видимо путаницу вносит то, что раньше в документации Solidity они явно писали про нулевой адрес при создании контракта, затем явно стали писать про null в поле to.
Отлично, разобрались, надо будет поправить статью вместе с правками опечаток )
===
Было:
Transactions
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below). It can include binary data (its payload) and Ether.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
===
Стало:
Transactions
A transaction is a message that is sent from one account to another account (which might be the same or empty, see below). It can include binary data (which is called “payload”) and Ether.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is not set (the transaction does not have a recipient or the recipient is set to null), the transaction creates a new contract.
С null vs 0 это видимо общая проблема во всем Computer Science, легко написать одно вместо другого.
Кстати, в самом Solidity это получаются равнозначные понятия потому что там пустой адрес создать не получится, он всегда будет иметь 20 байт, и по умолчанию это будут нули. Возможно это сыграло роль.
Лучше наверное смотреть спеку где:
The address hash
Ttis [...] is either a 20-byte address hash or, in the case of being a contract-creation transaction (and thus formally equal to ∅), it is the RLP empty byte sequence [...]
Можно указать любой другой адрес, как вы и сказали.
Но, скорей всего, был выбран именно тот, для которого не существует приватного ключа, то есть, координата (публичный ключ) не лежит на элеептической кривой. Что не позволяет иметь приватный ключ (число на которе умножается точка генерации G).
Адреса в Ethereum