Проблемы с Значением Nonce в Ethereum (Kin)

Мы ожидаем, что пользователи будут отправлять несколько транзакций в Kin  - подряд. Мы не хотим,  чтобы пользователи понимали суть блокчейна и мониторили свои транзакции вручную. При тестировании нашего кошелька SDK Kin (на Android и iOS) у нас была проблема с отправкой нескольких транзакций одна за другой. В определенный период времени все наши транзакции застревали и мы не могли видеть, что они находятся в режиме ожидания, в конце концов они отменялись. Как оказалось, транзакции имели одинаковые значение nonce для нескольких транзакций.

(* Чтобы проще понимать что такое nonce  в криптографии это одноразовый код, выбранный случайным или псевдослучайным образом, который используется для безопасной передачи основного пароля, предотвращая атаку повторного воспроизведения)


           Что такое nonce?

Nonce может означать две вещи в Эфириуме:

  • Доказательство работы nonce: бессмысленное значение в блоке, которое можно отрегулировать, чтобы попытаться удовлетворить  условие "proof of work". В этом суть майнинга и в какой-то степени алгоритма "proof of work".
  •  Account nonce: счетчик транзакций в каждом аккаунте, который предотвращает повторные атаки (double-spend). Например, транзакция, отправляющая 20 монет от A до B, может повторяться снова и снова аккаунтом B, чтобы постоянно сливать монеты с баланс A.


Наша проблема связана с последним nonce - счетчиком транзакций. При совершении транзакции в сети Ethereum к каждой транзакции в той же учетной записи должен быть присвоен последовательный номер. Каждая нода обрабатывает транзакции с определенного адреса  в строгом порядке в соответствии со значением его nonce.


Следовательно, при неправильном приращении этого значения могут возникнуть различные ошибки. К примеру, скажем,  что последняя транзакция nonce была равна 121:

  •  Повторное использование nonce: если мы отправим новую транзакцию для одного и того же аккаунта с номером nonce-121 или ниже, нода отклонит эту транзакцию.
  •  «Пробелы» : если мы отправим новую транзакцию с номером nonce-123 или выше, транзакция не будет обработана до тех пор, пока этот разрыв не будет закрыт, то есть до тех пор, пока транзакция с nonce-122 не будет обработана.


Определение nonce для транзакций

Как уже упоминалось ранее, мы заметили, что мы отправляем транзакции с одинаковыми значениями nonce. Чтобы объяснить, как это произошло, давайте сначала поймем, как мы увеличиваем значение nonce в наших мобильных SDK. Мы используем метод Geth (EthereumClient.getPendingNonceAt), который принимает общедоступный адрес аккаунта в качестве параметра. Этот метод в конечном итоге сопоставляется с API-интерфейсом eth_getTransactionCount JSON-RPC с  параметром «pending». Помните, что nonce - это количество транзакций в этом контексте.

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

eth_getTransactionCount с параметром «ожидающий» принимает последнее значение nonce из последнего добытого блока и добавляет транзакции, находящиеся в отложенном блоке, игнорируя при этом любые транзакции, которые могут висеть в ожидании  txpool.

Теперь нам стало ясно, что вызвало проблему - мы столкнулись с пиком пропускной способности тестовой сети Ethereum. Наши транзакции были поставлены в очередь в txpool, и мы долго не могли отправить их в ожидающий блок. В конце концов, когда наши транзакции продвигались в очереди txpool и были обработаны, они были отклонены, так как использовали тоже самое значение для nonce.


     Возможные Решения

1. Выполнение тяжелой работы на стороне клиента: Поиск последнего подходящее значения nonce на стороне клиента.

Используя Ethereum JSON-RPC, самый близкий способ получить ожидающую транзакцию - получить отложенный блок с использованием eth_getBlockByNumber и итерировать по всем транзакциям. Этот метод не имеет фильтра, поэтому мы должны искать транзакции с нашего адреса. Оставим в стороне тот факт, что он может включать в себя десятки транзакций (которые мы должны скачать и разобрать в мобильном клиенте). Мы просто получим такой  же результат, что и при использовании eth_getTransactionCount, поскольку мы мониторим только ожидающий блок.

Другим вариантом получения истинного значения nonce, является доступ ко всему txpool, поиск соответствующих транзакций там и выводить правильное значения  следующего nonce. Для этого мы можем использовать специальные API-интерфейсы Ethereum, связанные с txpool, называемые «API управления».

2. Усовершенствование серверной части (ноды): изменить логику на стороне сервера, чтобы просматривать весь txpool вместо ожидающего блока.

На гитахабе в go-ethereum есть открытая заяка, чтобы изменить это поведение, а в ноде есть собственное решение - нестандартное API parity_nextNonce, которое возвращает следующий доступный nonce как от ожидающего блока, так и от txpool. 

   Вывод

Хоть это и похоже на разумное решение, использование nonce, полученного из txpool,  несет в себе свои собственные риски. В случае, где мы отправляем несколько транзакций, мы можем перейти в состояние, в котором существует несколько транзакций в txpool. Если одна из этих транзакций недействительна и нода отклоняет ее, могут быть созданы "дыры" в подсчете транзакций. Это может привести к висячим транзакциям, которые не обрабатываются до тех пор, пока мы не заполним этот пробел. Так же это может быть очень сложно обнаружить и решить на стороне клиента.

Другая не определенная область - это то, что произойдет, когда ноды синхронизируются. Когда ноды объявляют новые транзакции другим узлам, а другие узлы объединяют эту новую информацию в свой собственный пул, что происходит с последним значенем nonce? Что произойдет, когда одна транзакция будет отправлена ​​на узел A, а вторая - в узел B? Последствия неясны. В отношении этих проблем, будущее решение может включать в себя - механизм дросселирования, который не позволит клиенту отправлять дополнительные транзакции при выполнении определенных условий.

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


Оригинальная статья  - тут

kinkik
115
10.771 GOLOS
0
В избранное
dinc
На Golos с 2017 M05
115
0

Зарегистрируйтесь, чтобы проголосовать за пост или написать комментарий

Авторы получают вознаграждение, когда пользователи голосуют за их посты. Голосующие читатели также получают вознаграждение за свои голоса.

Зарегистрироваться
Комментарии (1)
Сортировать по:
Сначала старые