Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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 просто зарегать онлайн нового пира и все работает
    Asmor-K
    @Asmor-K
    Добрый день, может ли блокчейн (апи и консенсус часть) использовать https?
    Asmor-K
    @Asmor-K
    И еще один вопрос почему хранилище у аудиторов занимает гораздо меньше места 1.4gb против 13gb, он хранит не все данные? и если так, то что он делает когда нужны те, что у него отсутствуют
    Arsen Guzhva
    @Erchard
    Есть сеть нод. Первая нода была поднята несколько месяцев назад. Новые ноды синхронизируются с ней, но скорост ьсинхронизации меньше чем скорость появления новых блоков. На что следует обратить внимание, чтобы ускорить синхронизацию?
    Asmor-K
    @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)" }
    В чем может быть проблема, почему она не закрывает соединения?
    Asmor-K
    @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

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

    Asmor-K
    @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, связанный с инстанциированием системных сервисов, существенно изменится в ближайшие недели при реализации динамических сервисов.

    Rouc4
    @Rouc4
    @dmitry-timofeev спасибо! Очень признателен за ответ!
    Aleksey Sidorov
    @alekseysidorov
    Еще хочу заметить, что если добавленый таким ad-hoc способом сервис имеет state hash, то он его не должен вычислять для высот меньше, чем момент добавления сервиса. Иначе это сломает работу аудиторов
    Rouc4
    @Rouc4
    @alekseysidorov, понял. Спасибо! Буду изучать.
    Elena Buzovska
    @Buzovska
    @/all Самое время зарегистрироваться на бесплатный вебинар для разработчиков от Exonum. Мы покажем как разработать электронный аукцион на блокчейн. Зарегистрироваться сейчас: https://bitfury.zoom.us/webinar/register/6315689822497/WN_pZf4qC9YQWKrm_6poKyzIA
    Asmor-K
    @Asmor-K
    Добрый день, могут ли ноды, в частности валидаторы, иметь одинаковые сервисные ключи?
    Rouc4
    @Rouc4
    @Asmor-K что вы подразумеваете под сервисными ключами? Всем ДД!
    Aleksey Sidorov
    @alekseysidorov
    Нет, там в коде теперь есть проверка, чтобы все ключи были уникальными, иначе это делает решение небезопасным