Что делать, если время выполнения для скрипта с альт-монетой превышает время блокировки?

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

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

Учитывая, что по мере роста размеров различных блоков монет ... Возможно, больше, чем 1 мб, этот риск также увеличится, учитывая большее количество транзакций.

Итак, мой вопрос:

  • Когда сценарии транзакций оцениваются (или нет)?

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

  • Какую роль играет загрузка процессора в сети и риск развития вилки?

Возможно, только шахтеры затронуты ... Я не уверен.

  • Если сеть с полным узлом имеет проблемы с пропускной способностью с процессором или пропускной способностью, может возникнуть вилка?
3 голоса | спросил random65537 12 MaramWed, 12 Mar 2014 09:00:10 +04002014-03-12T09:00:10+04:0009 2014, 09:00:10

3 ответа


2

Вам не нужно беспокоиться об этом, когда-либо происходящем.

В сценариях нет кодовых кодов операций. Каждый код кода сценария может выполняться только один раз, а самый медленный код операции, вероятно, является проверкой подписи ECDSA (поскольку он включает EC_point_multiply). Тем не менее, это займет всего около 50 ~ 100 мкс на одном ядре современного процессора для обработки.

Предположим, что 1 МБ-блок (максимальный размер) содержит 100% -ный код подтверждения подписи, это 1 млн подписи и занимает не более 100 секунд процессорного времени одного ядра, это все еще намного меньше, чем время блока. На практике каждый скриптSig сопровождается не менее чем 100 байтами данных (pubkey + ECDSA-подпись), поэтому он, вероятно, занимает менее 1 секунды времени процессора.

ответил uminatsu 12 MaramWed, 12 Mar 2014 10:19:52 +04002014-03-12T10:19:52+04:0010 2014, 10:19:52
2

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

Это одна из проблем, связанных с увеличением размера блока до примерно 8 МБ.

Расти Рассел обсуждает в сообщении о мегатрансформации ( https://rusty.ozlabs.org/? р = 522 ).

Согласно Расти

  

, если блоки были 8 МБ: транзакция 8 МБ с 22 500 входами и 3,95 МБ   выходов занимает более 11 минут для хэша. Если вы можете   вы можете навсегда удерживать конкурентов от ваших каблуков и владеть   биткойн-сеть

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

ответил Jonathan 14 Mayam16 2016, 04:38:33
0

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

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

ответил John T 13 MaramThu, 13 Mar 2014 01:12:23 +04002014-03-13T01:12:23+04:0001 2014, 01:12:23

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132