Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dmitry Timofeev
    @dmitry-timofeev

    В какой момент возвращает? При исполнении транзакции? Либо в ответ на отправку транзакции от лёгкого клиента?

    Хеш считается от полного сообщения транзакции в двоичном виде (т.е. сериализованные заголовок + тело + подпись). Блокчейн не модифицирует это двоичное сообщение, поэтому при исполнении транзакции хеш должен получиться тот же, что был у отправленного сообщения. В 0.9, кстати, на пользователе, реализующем транзакции была ответственность проверить подпись этой транзакции — если ли эта проверка в вашей реализации и успешно ли она проходит? Если успешно — то сообщение должно быть целостным.

    Да, подпись помещалась в конец сообщения в 0.1-0.9, а на той схеме — она в начале сообщения.

    Vladislav Karnaukhov
    @Asmor-K
    Добрый день, интересует вопрос, если запускать блокчейн с N сервисами, то транзакции будут выполняться синхронно в рамках всего блокчейна, а не конкретного сервиса? Если запусить несколько блокчейнов с 1-2 сервисом, то транзакцию уже будут выполняться синхронно для каждого блокчейна(сервиса) отдельно и соотвественно больше пропускная способность? Если запустить таким образом несколько блокчейнов на одной машине, то блокчейнам не нужно будет общаться через рест, они смогут читать другой блокчейн через RocksDB, если будут знать index_name?
    Dmitry Timofeev
    @dmitry-timofeev

    @Asmor-K , добрый день, а что подразумевается под "синхронностью" исполнения транзакций? Они исполняются асинхронно (с т.з. отправителя, будь то внешний клиент, будь то сервис). Те, которые избраны для включения в следующий блок, исполняются последовательно в некотором порядке (сейчас — в лексикографическом порядке хешей сообщений, что для клиента — случайный порядок). Поэтому относительный порядок транзакций разных сервисов произвольный. Подробнее о жизненном цикле транзакций можно узнать в доках: https://exonum.com/doc/version/0.11/architecture/transactions/#lifecycle

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

    Что касается пропускной способности, то в 0.12 или след. версиях планируется параллельно выполнять верификацию транзакций, возможно, и их исполнение, что должно повысить коэффициент использования ЦПУ и быстродействие. Если есть предложения по этим либо другим мерам по ускорению — пожалуйста, дайте знать тут либо на гитхабе.

    Взаимодействие же между сервисами в различных, независимых сетях через разделяемую локальную роксдиби — не поддерживается и, вероятно, потребует патча икзонума (если вообще осуществимо). Взаимодействие между сервисами в одной сети (в дополнение к вз-ю через разделяемые данные в БД) планируется добавить после 1.0.

    Vladislav Karnaukhov
    @Asmor-K
    Спасибо за полезную информацию. Интересует еще один вопрос, как сделать возможность отвечать в АПИ любым статусом ошибки, а не только NotFound, Unauthorized, BadRequest, InternalServerError и можно ли сделать тело ошибки в JSONе?
    Aleksey Sidorov
    @alekseysidorov
    Там есть возможность обратиться в service api builder к web backend, а в нем добавить raw handler с полным контролем над response
    Vladislav Karnaukhov
    @Asmor-K
    @alekseysidorov это очень радует, попробую разобраться на днях. Спасибо за ответ)
    Dmitry Timofeev
    @dmitry-timofeev

    Выпустили Exonum Java 0.7.0 с поддержкой тесткита для интеграционного тестирования Java-сервисов и огромным ускорением обработки транзакций :tada:

    Подробнее на странице выпуска: https://github.com/exonum/exonum-java-binding/releases/tag/ejb%2Fv0.7.0

    Arsen Guzhva
    @Erchard
    Где можно прочитать про запуск аудирующей ноды? Изменилось ли что-то по сравнению с версией 0.9 ?
    Arsen Guzhva
    @Erchard
    @dmitry-timofeev спасибо. С вычислением хэша транзакции всё получилось
    Michael Popsuev
    @sheb-gregor
    @Erchard вкратце - она просто так не запускается.
    вариант 1 — первоначальный запуск сети ( с нулевого блока), когда в конфигах есть ноды валидаторы + ноды аудиторы — всё классно.
    вариант 2 — подключение нового аудитора к запущенной сети — получи тапком в лицо, не подключается и не синкается.
    Возможное решение: если в вашей ноде содержится configuration-service из поставки Exonum, нужно отправить транзакцию с апдейтом конфига (в нем добавить информацию про ноду-аудитора). Но я это так и не проверил ещё.
    Arsen Guzhva
    @Erchard
    О! норм. Это подойдет
    Возможность апдейтить конфиг была предусмотрена заранее
    А самого аудитора нужно как-то настраивать по особому?
    toml конфиг? Параметры command line при старте аудитора?
    Arsen Guzhva
    @Erchard
    Проблема решена. Все оказалось проще
    @sheb-gregor просто зарегать онлайн нового пира и все работает
    Vladislav Karnaukhov
    @Asmor-K
    Добрый день, может ли блокчейн (апи и консенсус часть) использовать https?
    Vladislav Karnaukhov
    @Asmor-K
    И еще один вопрос почему хранилище у аудиторов занимает гораздо меньше места 1.4gb против 13gb, он хранит не все данные? и если так, то что он делает когда нужны те, что у него отсутствуют
    Arsen Guzhva
    @Erchard
    Есть сеть нод. Первая нода была поднята несколько месяцев назад. Новые ноды синхронизируются с ней, но скорост ьсинхронизации меньше чем скорость появления новых блоков. На что следует обратить внимание, чтобы ускорить синхронизацию?
    Vladislav Karnaukhov
    @Asmor-K
    Добрый день, бывают случаи, что нода начинает бесконечно падать с ошибкой thread 'main' panicked at 'Node return error: ErrorMessage { msg: "An error in the Network thread occurred: Too many open files (os error 24)" }
    В чем может быть проблема, почему она не закрывает соединения?
    Vladislav Karnaukhov
    @Asmor-K

    Aug 07 12:14:17 Node blockchain_core[12990]: thread '<unnamed>' panicked at 'called Result::unwrap() on an Err value: Os { code: 107, kind: NotConnected, message: "Transport endpoint is not connected" }', src/libcore/result.rs:997:5
    Aug 07 12:14:17 Node blockchain_core[12990]: note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
    Aug 07 12:14:17 Node blockchain_core[12990]: stack backtrace:
    Aug 07 12:14:17 Node blockchain_core[12990]: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
    Aug 07 12:14:17 Node blockchain_core[12990]: 1: std::sys_common::backtrace::_print
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys_common/backtrace.rs:71
    Aug 07 12:14:17 Node blockchain_core[12990]: 2: std::panicking::default_hook::{{closure}}
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys_common/backtrace.rs:59
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:197
    Aug 07 12:14:17 Node blockchain_core[12990]: 3: std::panicking::default_hook
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:211
    Aug 07 12:14:17 Node blockchain_core[12990]: 4: std::panicking::rust_panic_with_hook
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:478
    Aug 07 12:14:17 Node blockchain_core[12990]: 5: std::panicking::continue_panic_fmt
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:381
    Aug 07 12:14:17 Node blockchain_core[12990]: 6: rust_begin_unwind
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:308
    Aug 07 12:14:17 Node blockchain_core[12990]: 7: core::panicking::panic_fmt
    Aug 07 12:14:17 Node blockchain_core[12990]: at src/libcore/panicking.rs:85
    Aug 07 12:14:17 Node blockchain_core[12990]: 8: core::result::unwrap_failed
    Aug 07 12:14:17 Node blockchain_core[12990]: 9: exonum::events::network::NetworkHandler::build_handshake_initiator

    Так же заметил сейчас, что валидаторы постоянно стали паниковать. Делают пару коммитов, падают по данной причине и перезагружаются и так по кругу.
    В чем может быть проблема? Раньше такого не было

    Vladislav Karnaukhov
    @Asmor-K
    Добрый день, делал переезд нод на другую машину, скопировал базу от одного валидотара всем другим нодам, все работает, но в логах постоянно вылазит ошибка Received outdated Connect message from 192.168.88.45:6330 со старыми адресами пиров, можно это как то исправить?
    Arsen Guzhva
    @Erchard
    аналогичная пробелема. В логах постоянно фигурируют старые пиры, котоыре давно уже не существуют. Как почистить "кэш" ?
    Oleksandr Anyshchenko
    @aleksuss
    Опубликовали релиз Exonum 0.12 "Koepcke's Screech-Owl" c хранилищем MerkleDB и упрощенной процедурой запуска. Полный набор изменений можно посмотреть на странице релиза: https://github.com/exonum/exonum/releases/tag/v0.12

    Добрый день, может ли блокчейн (апи и консенсус часть) использовать https?

    На текущий момент нет. В планах имеется добавление протокола HTTPS.

    ivan-ochc
    @ivan-ochc
    @Asmor-K ,привет. А зачем Вы копируете базу одного валидатора всем остальным нодам? Если переносите ноду на новый сервер, копировать бд этой ноды всем остальным нодам не нужно.
    Michael Popsuev
    @sheb-gregor

    Кто-нибудь сталкивался с подобным?

    После того, как ноды упали, при попытке переподнять их возникает вот такая вот проблема:

    [2019-09-09T11:17:03.408284881Z INFO  exonum::node] Validator id = 'Some(ValidatorId(0))'
    [2019-09-09T11:17:03.442365728Z INFO  exonum::helpers::config] ConfigManager started
    [2019-09-09T11:17:03.442459399Z INFO  exonum::api::backends::actix] Starting public web api on 0.0.0.0:18002
    [2019-09-09T11:17:03.442521456Z INFO  actix_net::server::server] Starting 8 workers
    [2019-09-09T11:17:03.443372265Z INFO  actix_net::server::server] Starting server on 0.0.0.0:18002
    [2019-09-09T11:17:03.443438153Z INFO  exonum::api::backends::actix] Starting private web api on 0.0.0.0:19002
    [2019-09-09T11:17:03.443479929Z INFO  actix_net::server::server] Starting 8 workers
    [2019-09-09T11:17:03.444183831Z INFO  actix_net::server::server] Starting server on 0.0.0.0:19002
    [2019-09-09T11:17:03.444346098Z INFO  exonum::node] Start listening address=0.0.0.0:17002
    [2019-09-09T11:17:03.444360506Z INFO  exonum::node] Trying to connect with peer b374d5c1...
    [2019-09-09T11:17:03.444380027Z INFO  exonum::node] Trying to connect with peer c0f943b3...
    [2019-09-09T11:17:03.444383827Z INFO  exonum::node] Trying to connect with peer 75171b46...
    [2019-09-09T11:17:03.444412061Z INFO  exonum::node] Jump to round 8
    thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
    stack backtrace:
       0: backtrace::backtrace::libunwind::trace
                 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
       .....
      10: core::panicking::panic
                 at src/libcore/panicking.rs:49
      11: exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V>::get_root_node
      12: <exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V> as exonum_merkledb::hash::ObjectHash>::object_hash
      13: exonum::blockchain::schema::Schema<T>::core_state_hash
      14: exonum::blockchain::Blockchain::create_patch
      15: exonum::node::consensus::<impl exonum::node::NodeHandler>::execute
      16: exonum::node::consensus::<impl exonum::node::NodeHandler>::lock
      17: exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_majority_prevotes
      18: exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_consensus
      19: exonum::node::basic::<impl exonum::node::NodeHandler>::handle_message
      20: exonum::node::NodeHandler::initialize
      21: exonum::node::Node::run_handler
      22: exonum::node::Node::run
      23: exonum::helpers::fabric::builder::NodeBuilder::run
      24: node::main
    ivan-ochc
    @ivan-ochc
    @sheb-gregor, а какая была причина падения?
    Michael Popsuev
    @sheb-gregor
    @ivan-ochc место закончилось на сервере, тестовое окружение, после переноса на другой - вот такая фигня
    ivan-ochc
    @ivan-ochc
    @sheb-gregor, сейчас проверю
    ivan-ochc
    @ivan-ochc
    @sheb-gregor , все ноды были запущены на одном окружении?
    ivan-ochc
    @ivan-ochc
    @sheb-gregor, повторить не получается: на одном сервере запустил две ноды, подождал пока закончилось место и ноды упали, скопировал бд и конфиги на новый сервер, запустил ноды - ошибки нет.
    Michael Popsuev
    @sheb-gregor
    @ivan-ochc да, на одном
    мне кажется проблема в Jump to round 8 — нужно подчистить прекоммит сообщения и незакрытые раунды консенсуса
    ivan-ochc
    @ivan-ochc
    у меня было Jump to round 6
    [2019-09-09T13:05:43.651044414Z INFO  exonum::node] Start listening address=0.0.0.0:6331
    [2019-09-09T13:05:43.651068842Z INFO  exonum::node] Trying to connect with peer 60d8aba6...
    [2019-09-09T13:05:43.651116693Z INFO  exonum::node] Jump to round 6
    [2019-09-09T13:06:06.149348229Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=6
    [2019-09-09T13:06:10.949306748Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=7
    [2019-09-09T13:06:16.049354965Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=8
    [2019-09-09T13:06:21.449359547Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=9
    [2019-09-09T13:06:26.740166733Z INFO  exonum::node::basic] Received Connect message from peer: In(V4(127.0.0.1:26509))
    [2019-09-09T13:06:26.740194196Z INFO  exonum::node::basic] Received Connect message from 127.0.0.1:6332. Need to connect: true
    [2019-09-09T13:06:26.740263617Z INFO  exonum::node::basic] Send Connect message to 127.0.0.1:6332
    [2019-09-09T13:06:27.149395253Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=10
    [2019-09-09T13:06:27.253701274Z INFO  exonum::node::consensus] COMMIT ====== height=1619, proposer=1, round=1,
    ivan-ochc
    @ivan-ochc
    попробовал вариант когда заканчивается место во время принятия и обработки транзакций - так же ошибок не возникло
    Michael Popsuev
    @sheb-gregor
    хм, буду пытаться дальше ковырять
    Michael Popsuev
    @sheb-gregor
    [2019-09-10T14:41:23.598719879Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17004. Need to connect: false
    [2019-09-10T14:41:33.598873319Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17001. Need to connect: false
    [2019-09-10T14:41:33.599055887Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
    [2019-09-10T14:41:43.600487308Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17001. Need to connect: false
    [2019-09-10T14:41:43.600675047Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
    [2019-09-10T14:41:47.562212900Z WARN  exonum::node::consensus] ROUND TIMEOUT height=11871804, round=40
    [2019-09-10T14:41:53.601312843Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17004. Need to connect: false
    [2019-09-10T14:41:53.601495522Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
    [2019-09-10T14:42:02.562317217Z WARN  exonum::node::consensus] ROUND TIMEOUT height=11871804, round=41
    [2019-09-10T14:42:02.762414634Z INFO  exonum::node::consensus] LEADER: pool = 0, cache = 0
    thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
    stack backtrace:
       0:     0x5604c625631b - backtrace::backtrace::libunwind::trace::hfe5db90796807973
                                   at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
       1:     0x5604c625631b - backtrace::backtrace::trace_unsynchronized::h34b865a835594335
                                   at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
       2:     0x5604c625631b - std::sys_common::backtrace::_print::h527254ae44989167
                                   at src/libstd/sys_common/backtrace.rs:47
       3:     0x5604c625631b - std::sys_common::backtrace::print::he85dd5ddddf46503
                                   at src/libstd/sys_common/backtrace.rs:36
       4:     0x5604c625631b - std::panicking::default_hook::{{closure}}::h847a2eb38b396f14
                                   at src/libstd/panicking.rs:200
       5:     0x5604c6255ff7 - std::panicking::default_hook::h2ca0f9a30a0e206b
                                   at src/libstd/panicking.rs:214
       6:     0x5604c6256b79 - std::panicking::rust_panic_with_hook::hffcefc09751839d1
                                   at src/libstd/panicking.rs:481
       7:     0x5604c6256612 - std::panicking::continue_panic_fmt::hc0f142c930c846fc
                                   at src/libstd/panicking.rs:384
       8:     0x5604c62564f6 - rust_begin_unwind
                                   at src/libstd/panicking.rs:311
       9:     0x5604c627798d - core::panicking::panic_fmt::h2daf88b2616ca2b2
                                   at src/libcore/panicking.rs:85
      10:     0x5604c62778cc - core::panicking::panic::h2d0bc53a963fb996
                                   at src/libcore/panicking.rs:49
      11:     0x5604c5b2b01a - exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V>::get_root_node::ha2a1f60e285bfe04
      12:     0x5604c5b29d25 - <exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V> as exonum_merkledb::hash::ObjectHash>::object_hash::h5af234c972d8344d
      13:     0x5604c5a30fef - exonum::blockchain::schema::Schema<T>::core_state_hash::h44801c972bf3e638
      14:     0x5604c5b7f7d9 - exonum::blockchain::Blockchain::create_patch::h60023d4156a96062
      15:     0x5604c5c015a0 - exonum::node::consensus::<impl exonum::node::NodeHandler>::execute::he00384f9a3e8c590
      16:     0x5604c5bfc19d - exonum::node::consensus::<impl exonum::node::NodeHandler>::lock::h194ef9c313111d3e
      17:     0x5604c5bfb7d4 - exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_majority_prevotes::h6b590da2fd3fcf9c
      18:     0x5604c5bf72d7 - exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_consensus::hd5b8c83023b4c029
      19:     0x5604c5bf39ef - exonum::node::basic::<impl exonum::node::NodeHandler>::handle_message::hf7e461ea01821507
      20:     0x5604c5c03576 - exonum::node::events::<im
    3 ноды запущены, 4 пытается догнать блоки
    Все три периодически падают с паникой
    ivan-ochc
    @ivan-ochc
    Это тот же сценарий когда переносят ноды на новый сервер или уже другое?
    Michael Popsuev
    @sheb-gregor
    и не поднимаются пока не сделаешь maintenance --action clear-cache
    потом снова падают
    4я в фоне блоке тащит, пока все три не отпадут
    ivan-ochc
    @ivan-ochc
    @sheb-gregor, это тот же сценарий с переносом на новый сервер или уже на одном и том же сервере паникуют?
    Michael Popsuev
    @sheb-gregor
    на новом сервере
    Gab0
    @breseda
    Hola desde mexico
    Rouc4
    @Rouc4
    Всем привет! Ребят подскажите, существует ли такая возможность запустить сервис на java-binding параллельно существующему проекту exonum на 0.12.0 версии (возможно с рестартом сети узлов или без такового)? Т.е. один блокчейн с двумя рантаймами, но одной базой?
    Dmitry Timofeev
    @dmitry-timofeev

    Привет, @Rouc4 ,

    Да, это возможно, если добавить в список растовых сервисов, вкомпилированных в приложение exonum-java, необходимые растовые сервисы. Пока это не очень удобно с т.з. сопровождения, т.к. exonum-java пока является только приложением, т.е. его нельзя, как икзонум, подключить в качестве библиотеки и при создании узла зарегистрировать дополнительные растовые сервисы, а нужно патчить. Кроме того, в 0.12 регистрация новых сервисов в запущенной сети имеет некоторые ограничения: требуется остановка сети, и отсутствие конфигурационных параметров у нового сервиса (всё это будет исправлено с поддержкой динамических сервисов, над которой сейчас работаем).

    Подробнее о том, как это сделать сейчас, не дожидаясь ДС (Exonum Java 0.8.0 based on Exonum 0.12.0):

    1. Ваши существующие растовые сервисы извлечь в отдельную библиотеку
    2. Склонировать exonum-java
    3. Модифицировать exonum-java, расширив список системных сервисов (см. метод prepare_service_factories as of ejb/v0.8.0). В exonum-java они конфигурируются, вы же можете регистрировать необходимые сервисы безусловно, что будет еще проще.
    4. Собрать модифицированное приложение (см. CONTRIBUTING.md) и использовать его для запуска узлов сети.

    
Последнее: стоит учитывать при планировании, что нативный код exonum-java, связанный с инстанциированием системных сервисов, существенно изменится в ближайшие недели при реализации динамических сервисов.