ziesha-network / bazuka Goto Github PK

• Implement BN254 required fields. (Use ff crate)
• Implement elliptic curve operations
• Implement MiMC hash function
• Implement EdDSA algorithm
• Check consistency with gnark Go library.

https://github.com/zeeka-network/bazuka/blob/6f63650f3e8642f96c04fbf274f2941525be2989/src/blockchain/mod.rs#L201

@kwanCCC This is the place that is triggered to generate a block. This function is called every 1s by the node software. If a block can be generated, it returns the block. If not, it returns None. It gets a Wallet (Which can be used to generate signed transactions, or VRF signatures, or idk) and a vector of transactions as its arguments. When you were mentioning "Keystore" earlier, you were probably mentioning "Wallet" I think. So, maybe we should change its name to Keystore, and also include VRF keys and stuff inside it if its needed. (If i'm saying nonesense, forgive me. I still don't know a lot about BABE)

Hi,

Where is the log files folder?

Best Regards

• Define block structure
• Define genesis block
• Implement regular + staking transactions
• POST + GET request for getting and proposing blocks to the network
• Implement BABE
• Implement GRANDPA

Panic occurs when running Zeeka as a non-root user

Platform: Linux Ubuntu 20.04.4

============================
Service file:

[Unit]
Description=Zeeka node
After=network.target

[Service]
User=zeeka_user
Environment=RUST_BACKTRACE=full
ExecStart=/home/zeeka_user/.cargo/bin/bazuka node --listen 0.0.0.0:8765 --external 38.242.242.5:8765 --network debug --db ~/.bazuka-debug --bootstrap 195.201.222.205:8765
Restart=on-failure
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

============================

thread 'main' panicked at 'called Result::unwrap() on an Err value: IO(Os { code: 13, kind: PermissionDenied, message: "Permission denied" })', src/main.rs:198:50
stack backtrace:
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
0: 0x5601a960bd6d - std::backtrace_rs::backtrace::libunwind::trace::h8217d0a8f3fd2f41
1: 0x5601a960bd6d - std::backtrace_rs::backtrace::trace_unsynchronized::h308103876b3af410
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x5601a960bd6d - std::sys_common::backtrace::_print_fmt::hc208018c6153605e
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:66:5
3: 0x5601a960bd6d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf89a7ed694dfb585
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:45:22
4: 0x5601a962e50c - core::fmt::write::h21038c1382fe4264
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/fmt/mod.rs:1197:17
5: 0x5601a96063d1 - std::io::Write::write_fmt::h7dbb1c9a3c254aef
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/io/mod.rs:1672:15
6: 0x5601a960d515 - std::sys_common::backtrace::_print::h4e8889719c9ddeb8
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:48:5
7: 0x5601a960d515 - std::sys_common::backtrace::print::h1506fe2cb3022667
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:35:9
8: 0x5601a960d515 - std::panicking::default_hook::{{closure}}::hd9d7ce2a8a782440
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:295:22
9: 0x5601a960d236 - std::panicking::default_hook::h5b16ec25444b1b5d
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:314:9
10: 0x5601a960daa6 - std::panicking::rust_panic_with_hook::hb0138cb6e6fea3e4
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:698:17
11: 0x5601a960d997 - std::panicking::begin_panic_handler::{{closure}}::h4cb67095557cd1aa
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
12: 0x5601a960c224 - std::sys_common::backtrace::__rust_end_short_backtrace::h2bfcac279dcdc911
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
13: 0x5601a960d6c9 - rust_begin_unwind
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
14: 0x5601a91ad653 - core::panicking::panic_fmt::h1de71520faaa17d3
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
15: 0x5601a91ad743 - core::result::unwrap_failed::hc0baa33ef8bc7db8
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/result.rs:1805:5
16: 0x5601a92024fb - bazuka::main::{{closure}}::h0543c85275a57e28
17: 0x5601a92eb34d - std::thread::local::LocalKey::with::h1eb993e565e9039a
18: 0x5601a933de72 - tokio::park::thread::CachedParkThread::block_on::hd96fde8c1fc9edf1
19: 0x5601a92601ac - tokio::runtime::scheduler::multi_thread::MultiThread::block_on::h5bf381e8a6281341
20: 0x5601a928f6de - tokio::runtime::Runtime::block_on::hbd46a33906755eb1
21: 0x5601a92e6153 - bazuka::main::h31b74a6d13562dce
22: 0x5601a9325226 - std::sys_common::backtrace::__rust_begin_short_backtrace::h8f364d2842a026fd
23: 0x5601a92227c5 - std::rt::lang_start::{{closure}}::he089c7328dfbd009
24: 0x5601a9600cbe - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::h4937aaa125c8d4b2
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:280:13
25: 0x5601a9600cbe - std::panicking::try::do_call::h6f5c70e8b0a34f92
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40
26: 0x5601a9600cbe - std::panicking::try::h68766ba264ecf2e2
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19
27: 0x5601a9600cbe - std::panic::catch_unwind::hc36033d2f9cc04af
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14
28: 0x5601a9600cbe - std::rt::lang_start_internal::{{closure}}::h78c037f4a1a28ded
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:48
29: 0x5601a9600cbe - std::panicking::try::do_call::he6e1fffda4c750ee
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40
30: 0x5601a9600cbe - std::panicking::try::h48a77ddbb2f4c87a
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19
31: 0x5601a9600cbe - std::panic::catch_unwind::hfa809b06a550a9e7
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14
32: 0x5601a9600cbe - std::rt::lang_start_internal::h4db69ed48eaca005
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:20
33: 0x5601a92e6232 - main
34: 0x7f5a6fa08083 - __libc_start_main
35: 0x5601a91ae52e - _start
36: 0x0 -

When I run bazuka wallet new-token --amount 1000 --decimals 2 --symbol MYCOIN --name "My Coin", The balance I see for my new token should be 1000.0, no anything else!

Currently, when you send a tx with bazuka wallet ... command, the transaction is sent and propagated through the network even if the tx is obviously invalid (Balance insufficiency/Invalid nonces/etc) and cannot be applied. The network will not process any transactions (Even if valid) coming after the faulty transactions because of the invalid nonces.
The problem can be partially solved if we query the server regarding validity of the transaction before actually putting it in the mempool. We will need a new API endpoint: GET /bincode/transact/check

These message types:

struct CheckTransactionRequest {
  pub tx_delta: TransactionAndDelta
}
struct CheckTransactionResponse {
  pub error: Option<String>
}

A new function fn check_tx(&self, tx: Transaction) -> Result<(), BlockchainError>; should be added to Blockchain trait, which will just apply_tx(&tx)? in an isolated environment and will propagate error if there is any.

All CLI commands that create txs (bazuka wallet send, bazuka wallet new-token, bazuka wallet register-validator, ...), should first check validity of tx through this API call and send the transaction only if there is no error.

Hello,

We've tried to activate or update your repository on Depfu and couldn't find any supported dependency files. If we were to guess, we would say that this is not actually a project Depfu supports and has probably been activated by error.

Monorepos

Please note that Depfu currently only searches for your dependency files in the root folder. We do support monorepos and non-root files, but don't auto-detect them. If that's the case with this repo, please send us a quick email with the folder you want Depfu to work on and we'll set it up right away!

How to deactivate the project

• Go to the Settings page of either your own account or the organization you've used
• Go to "Installed Integrations"
• Click the "Configure" button on the Depfu integration
• Remove this repo (ziesha-network/bazuka) from the list of accessible repos.

Please note that using the "All Repositories" setting doesn't make a lot of sense with Depfu.

If you think that this is a mistake

Please let us know by sending an email to [email protected].

This is an automated issue by Depfu. You're getting it because someone configured Depfu to automatically update dependencies on this project.

• Implement the gnark library BN254 rollup contract
• Implement contract creation transaction (To store verifying keys)
• Store verifying keys of the MPN contract on genesis block
• Implement PLONK validation on Rust (Either natively or using bindings to the gnark library)
• Implement contract update transaction (Check proof while validating blocks)

bazuka node start --develop will be a mode of running a node which will use an empty RamKvStore instead of a level-db KvStore and a different genesis block. A special config objects should also be defined for this kind of node: bazuka::config::blockchain::get_dev_blockchain_config(initial_validator: Address).

This function is the same with get_blockchain_config() with the difference that its initial validator is given through an argument. Initial validator could be the public-key of runner's wallet.

Right now, bazuka node status returns the following output if node is not running:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ServerError(hyper::Error(Connect, ConnectError("tcp connect error", Os { code: 111, kind: ConnectionRefused, message: "Connection refused" })))', src/main.rs:371:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Instead, it is better to inform user with a message Node Stopped or Node is not running.

How to solve this problem?
Error: called Result::unwrap() on an Err value: ServerError(hyper::Error(Io, Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }))

Your regular and zero-knowledge private-keys are derived from the --seed value, so don't forget to keep them somewhere safe! You can choose your target network (E.g mainnet, chaos, debug or etc.) through the --network option. You should also choose the node which you want to send your transactions to, through the --node option. (Here we choose our local node which we will run later)

Imagine someone sent a faulty (Or unwanted tx) to the network and it propagated to all nodes, user should be able to replace the faulty tx by sending a new tx with the same nonce and higher fee to the network!

• Remove warp and reqwest dependencies. They are large. Use hyper instead for both client/server ops.
• Implement UPnP port-forwarding using igd package.

• There should be a list of bootstrap nodes somewhere. Maybe put them on a GitHub repo.
• Nodes should be able to get initial nodes from bootstrap node list and discover the whole network. Nodes do this by introducing themselves through http POST requests to other nodes and discovering their peers through GET requests. This happens in a fixed interval.
• Nodes can filter the messages they want to receive from their peers through Bloom Filters. They submit their Bloom Filter in the introduction phase.

Hi, my zeeka node was working fine until an update one day, probably a month or so ago. Now it does not go beyond block one and I can see 'wrong network' error in logs.

I tried various ways to fix it but nothing helps.
Any suggestions please?

To compile bazuka on clear Debian/Ubuntu OS it is necessary to install the build-essential package

Without installing build-essential package, users may crash with this error:

error: failed to run custom build command for `rust-randomx v0.6.0`

Caused by:
  process didn't exit successfully: `/root/bazuka/target/release/build/rust-randomx-068b5a07964d3f6b/build-script-build` (exit status: 101)
  ........
  --- stderr
  CMake Error at CMakeLists.txt:31 (project):
    The CMAKE_CXX_COMPILER:

      c++

    is not a full path and was not found in the PATH.

    Tell CMake where to find the compiler by setting either the environment
    variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
    to the compiler, or to the compiler name if it is in the PATH.


  thread 'main' panicked at '
  command did not execute successfully, got: exit status: 1

  build script failed, must exit now', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.48/src/lib.rs:975:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

✅FIX: sudo apt-get install -y build-essential
💡 Add build-essential package to the command sudo apt install -y libssl-dev cmake which is in the first step of the documentation