3dpass / 3dp Goto Github PK

Implement Substrate im-online pallet: https://github.com/paritytech/substrate/tree/master/frame/im-online
Using this pallet, remove validators didn't provide an extrinsic confirmation from validator set.

Description

In Rust, a function can be marked as deprecated to indicate that the function shouldn't be used anymore in the future. Hence, consider avoiding the use of deprecated functions in your code as much as possible.

Occurrences

There are 3 occurrences of this issue in the repository.

See all occurrences on DeepSource → app.deepsource.com/gh/3Dpass/3DP/issue/RS-W1128/occurrences/

Motivation

According to the White Paper, we have to implement the Proof of Scan consensus algorithm into the NODE.

Suggested Solution

We have to replace existing block validation mechanism (POS or POW) with the 3D object recognition tool p3d we already have implemented into Substrate recently. This makes the NODE able to provide 3D objects authenticity check considering whether or not a new block might be added to the chain.

Alternatives

No alternatives

Additional Information

POS more likely fits to be modified.

i use dorker

miner | Error: connect ECONNREFUSED 172.18.0.2:9933
node | Error: Input("Invalid seed: InvalidFormat")
miner | Error: connect ECONNREFUSED 172.18.0.2:9933
node | 2022-07-24 07:58:04 Proof Of Scan Consensus Node (PoScan and Grandpa)
node | 2022-07-24 07:58:04 ✌️ version 3.0.0-unknown-x86_64-linux-gnu
node | 2022-07-24 07:58:04 ❤️ by Substrate DevHub https://github.com/substrate-developer-hub, 2019-2022
node | 2022-07-24 07:58:04 📋 Chain specification: 3DP testnet
node | 2022-07-24 07:58:04 🏷 Node name: old-agreement-4125
node | 2022-07-24 07:58:04 👤 Role: AUTHORITY
node | 2022-07-24 07:58:04 💾 Database: RocksDb at /var/chain/chains/3dp/db
node | 2022-07-24 07:58:04 ⛓ Native runtime: poscan-runtime-1 (poscan-runtime-1.tx1.au1)
node | 2022-07-24 07:58:04 🏷 Local node identity is: 12D3KooWJhwrfhG89ME27p6UrCtp4LmHi8heDrZGVga73JYj2CPc
node | 2022-07-24 07:58:04 📦 Highest known block at #0
node | 2022-07-24 07:58:04 〽️ Prometheus server started at 127.0.0.1:9615
node | 2022-07-24 07:58:04 Listening for new connections on 0.0.0.0:9944.
node | Error: Service(Other("Invalid author address"))
miner | Error: getaddrinfo ENOTFOUND node

why get this error message

Set up the genesis block content, addresses and balances.

Implement a filter which would rule out Grandpa validators, unless they meet a certain conditions:

• 10000 3DP locked on the author's account
• Author has mined at least one block during the last 100 blocks session

Set up mining rewards curve according to the description down the link: https://github.com/3Dpass/3DP/wiki/Commissions-and-rewards

Catch up with the actual master branch of Substrate instead of using v3.0

Motivation

In order to ensure decentralized exchange testnet 3DPs (mined over the test period) for mainnet 3DPs, we need Substrate-to-Substrate cross-chain bridge to be run.

Suggested Solution

We should use an Open Source existing solutions for Substrate

Alternatives
We can not see the reason, why we have to develop our own bridge, which is also possible.

Additional Information

Research required

Create a function which makes possible for users to submit a lock transaction:

• amount to be locked,
• target block for Unlock

The current bug/exploit is nearly the same with the last one and with my solution you solve it forever . You can make an object and you can hash it with a prehash like x y z 0 … it doesnt matter what are the values for x y z because the hash will be the same. So if you generate many blocks you can do the hardwork only once and then just do the sha3 part ( basically skip the main step in the hashing process ) .

solution : just check for the "empty" rotation (when the 4th byte is 0), so hashes with no rotation cannot be built

Optimize searching algorithm of 3D objects in the previous blocks in order to verify whether or not there is a copy cats in the chain.

4825add

Compilation error after replacing multiprocess file.

warning: H:\3DP\Cargo.toml: unused manifest key: workspace.librocksdb-sys
Compiling poscan-consensus v3.0.0 (H:\3DP\nodes\poscan-consensus)
error[E0706]: functions in traits cannot be declared async
--> nodes\poscan-consensus\src\service.rs:125:2
|
| async fn create_inherent_data_providers(
| ^----
| |
| async because of this
| |
| | &self,
| | _parent: ::Hash,
| | _extra_args: (),
| | ) -> Result<Self::InherentDataProviders, Box<dyn std::error::Error + Send + Sync>> {
| | Ok(sp_timestamp::InherentDataProvider::from_system_time())
| | }
| |^
|
= note: async trait functions are not currently supported
= note: consider using the async-trait crate: https://crates.io/crates/async-trait

error[E0432]: unresolved import sc_executor::NativeElseWasmExecutor
--> nodes\poscan-consensus\src\service.rs:6:5
|
6 | use sc_executor::NativeElseWasmExecutor;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no NativeElseWasmExecutor in the root

error[E0432]: unresolved import sc_consensus::DefaultImportQueue
--> nodes\poscan-consensus\src\service.rs:7:5
|
7 | use sc_consensus::DefaultImportQueue;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no DefaultImportQueue in the root

error[E0432]: unresolved import sc_telemetry
--> nodes\poscan-consensus\src\service.rs:10:5
|
| ^^^^^^^^^^^^ use of undeclared crate or module sc_telemetry

error[E0432]: unresolved import async_trait
--> nodes\poscan-consensus\src\service.rs:27:5
|
27 | use async_trait::async_trait;
| ^^^^^^^^^^^ use of undeclared crate or module async_trait

error: cannot determine resolution for the attribute macro async_trait
--> nodes\poscan-consensus\src\service.rs:121:3
|
121 | #[async_trait]
| ^^^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports

error[E0433]: failed to resolve: use of undeclared crate or module frame_benchmarking
--> nodes\poscan-consensus\src\service.rs:51:31
|
51 | type ExtendHostFunctions = frame_benchmarking::benchmarking::HostFunctions;
| ^^^^^^^^^^^^^^^^^^ use of undeclared crate or module frame_benchmarking

error[E0433]: failed to resolve: use of undeclared crate or module sc_telemetry
--> nodes\poscan-consensus\src\service.rs:172:33
|
172 | .map(|endpoints| -> Result<_, sc_telemetry::Error> {
| ^^^^^^^^^^^^ use of undeclared crate or module sc_telemetry

error[E0405]: cannot find trait CreateInherentDataProviders in crate sp_inherents
--> nodes\poscan-consensus\src\service.rs:122:20
|
122 | impl sp_inherents::CreateInherentDataProviders<Block, ()> for CreateInherentDataProviders {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in sp_inherents

error[E0425]: cannot find function protocol_standard_name in crate sc_finality_grandpa
--> nodes\poscan-consensus\src\service.rs:618:51
|
618 | let grandpa_protocol_name = sc_finality_grandpa::protocol_standard_name(
| ^^^^^^^^^^^^^^^^^^^^^^ not found in sc_finality_grandpa

Some errors have detailed explanations: E0405, E0425, E0432, E0433, E0706.
For more information about an error, try rustc --explain E0405.
error: could not compile poscan-consensus due to 10 previous errors

If an object has a face with at least 2 vertices with the same coordinates, that face does not affect the object's center of mass and inertia vectors, but does affect polylines
The currenly used method of slicing the object into 12 slices checks for vertices within 0.15 units from the slice plane, so if the object is really big, none of its vertices will intersect with any of the slices, grid2dv3a fixes this
The miner is using the reversed mining method, first finding a combination of polylines and then constructing an object from them, to do this it's first generating a normal random object and scaling it up until none of its vertices intersect with any of the 12 slice planes, then adds the polyline points as same vertex faces since they don't affect the object's rotation, the scaled up random object does not affect the hash, it just makes the object look normal
A possible fix is to discard any such faces and start using grid2dv3a's slicing algorithm

After running command:
cargo run --release -- --dev --tmp
the following output is produced:

Finished release [optimized] target(s) in 5m 16s
warning: the following packages contain code that will be rejected by a future version of Rust: fs_extra v1.2.0, nalgebra v0.27.1
note: to see what the problems were, use the option --future-incompat-report, or run cargo report future-incompatibilities --id 1
Running target/release/poscan-consensus --dev --tmp

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

Version: 3.1.0-79caf1b-x86_64-linux-gnu

0: sp_panic_handler::set::{{closure}}
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn>::call
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1999:9
std::panicking::rust_panic_with_hook
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:695:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:580:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/sys_common/backtrace.rs:151:18
4: rust_begin_unwind
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:578:5
5: core::panicking::panic_fmt
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/panicking.rs:67:14
6: <pallet_validator_set::pallet::GenesisConfig as frame_support::traits::hooks::GenesisBuild>::build
7: environmental::using
8: sp_state_machine::basic::BasicExternalities::execute_with_storage
9: <poscan_runtime::GenesisConfig as sp_runtime::BuildStorage>::assimilate_storage
10: sp_runtime::BuildStorage::build_storage
11: <sc_chain_spec::chain_spec::ChainSpec<G,E> as sp_runtime::BuildStorage>::build_storage
12: sc_service::client::client::Client<B,E,Block,RA>::new
13: sc_service::builder::new_full_parts
14: poscan_consensus::service::new_partial
15: poscan_consensus::service::new_full
16: tokio::park::thread::CachedParkThread::block_on
17: tokio::runtime::thread_pool::ThreadPool::block_on
18: tokio::runtime::Runtime::block_on
19: sc_cli::runner::Runner::run_node_until_exit
20: poscan_consensus::command::run
21: poscan_consensus::main
22: std::sys_common::backtrace::__rust_begin_short_backtrace
23: std::rt::lang_start::{{closure}}
24: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/ops/function.rs:284:13
std::panicking::try::do_call
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:485:40
std::panicking::try
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:449:19
std::panic::catch_unwind
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panic.rs:142:14
std::rt::lang_start_internal::{{closure}}
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/rt.rs:148:48
std::panicking::try::do_call
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:485:40
std::panicking::try
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:449:19
std::panic::catch_unwind
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panic.rs:142:14
std::rt::lang_start_internal
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/rt.rs:148:20
25: main
26:
27: __libc_start_main
28: _start

Thread 'main' panicked at 'Initial set of validators must be at least T::MinAuthorities', /root/3DP/pallets/validator-set/src/lib.rs:672

This is a bug. Please report it at:

    https://github.com/3Dpass/3DP/issues

Description

Checks for operations that evaluate to zero, such as 0 / y. This is most likely unintentional.

Occurrences

There is 1 occurrence of this issue in the repository.

See all occurrences on DeepSource → app.deepsource.com/gh/3Dpass/3DP/issue/RS-E1007/occurrences/

• linux system version

Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.3 LTS
Release:	22.04
Codename:	jammy

• error

Version: 3.1.0-9729e52-x86_64-linux-gnu

   0: sp_panic_handler::set::{{closure}}
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1999:9
      std::panicking::rust_panic_with_hook
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:695:13
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:582:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/sys_common/backtrace.rs:151:18
   4: rust_begin_unwind
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:578:5
   5: core::panicking::panic_fmt
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/panicking.rs:67:14
   6: core::panicking::panic_bounds_check
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/panicking.rs:162:5
   7: p3d::algo_grid::get_contour
   8: p3d::p3d_process_n
   9: poscan_algo::get_obj_hashes_n
  10: poscan_algo::get_obj_hashes
  11: <poscan_grid2d::PoscanAlgorithm<C> as sc_consensus_poscan::PowAlgorithm<B>>::verify
  12: <sc_consensus_poscan::PowBlockImport<B,I,C,S,Algorithm,CAW,CIDP> as sc_consensus::block_import::BlockImport<B>>::import_block::{{closure}}
  13: <alloc::boxed::Box<dyn sc_consensus::block_import::BlockImport<B>+Error = sp_consensus::error::Error+Transaction = Transaction+core::marker::Sync+core::marker::Send> as sc_consensus::block_import::BlockImport<B>>::import_block::{{closure}}
  14: <&mut F as core::future::future::Future>::poll
  15: sc_consensus::import_queue::basic_queue::BlockImportWorker<B>::new::{{closure}}
  16: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  17: <sc_service::task_manager::prometheus_future::PrometheusFuture<T> as core::future::future::Future>::poll
  18: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
  19: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll
  20: tokio::park::thread::CachedParkThread::block_on
  21: tokio::runtime::handle::Handle::block_on
  22: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  23: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  24: tokio::runtime::task::harness::Harness<T,S>::poll
  25: tokio::runtime::blocking::pool::Inner::run
  26: std::sys_common::backtrace::__rust_begin_short_backtrace
  27: core::ops::function::FnOnce::call_once{{vtable.shim}}
  28: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1985:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1985:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/sys/unix/thread.rs:108:17
  29: <unknown>
  30: <unknown>


Thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 0 but the index is 0', /home/runner/.cargo/git/checkouts/p3d-675c372166b26a37/cfd70b0/src/algo_grid.rs:533

This is a bug. Please report it at:

	https://github.com/3Dpass/3DP/issues

fix it please

Add objects recognition parameters used for mining into the block header:

• algorithm name (ex. Grid2d)
• cross sections (ex. -s=88)
• grid (ex. -g=8)

Check if they are used on new block import.

Set up 3D objects validation fee as % of the mining reward and divide it among all validators in equal.

If the validation has stalled (block finalized is falling behind the best block further than 10 blocks back) we have to force new session and put a validation trigger into the block at the beginning of the next session (ex. + 5 blocks)

When mining rewards are given out to a pool, each entry in pool's PowStat is given some amount of coins through

Run 3+ Nodes testnet and define the procedure check list

The mining tool has to keep generating new 3D models and process them through pass3d until it finds the one, so that HASH ID of which would correspond to the actual difficulty (The top hash of the HASH ID list must correspond to the actual difficulty).

Once the object is found, it is to push towards the Node via pushMiningObject RPC.

docker runs to
cargo build --release

and gets stuck
Reinstall the operating system several times, to no avail

Motivation

Smart Crypto Vault for assets, which allows to store in safe on the blockchain some expensive digital models as well as the real vault does. Both vaults real and virtual depend on each other.

Suggested Solution

The blockchain vault is linked together with a physical smart vault, the real assets to be stored in. Both vaults might be opened with 3Pass wallet keys. As the blockchain virtual vault got decrypted, the real vault opens.

Alternatives

Some research required

Additional Information

Feel free to provide your ideas

Multi-thread version of the Node consumes a lot of CPU itself, even without a minier being connected.

Test smart contracts pallet to be sure it executes substrate examples properly.

Implement the following pallets into Runtime:

1. Session
2. Smart Contracts
3. Democracy
4. Multisig

Improve the mining handler with multithread option. The process is implemented in service.rs

Explore how it works in Kulupu and apply a similar idea into 3DPass.

Align all the network account addresses with the KeyType="3DP_" and test the mining rewards to receive using front-end template. Set up mining rewards = 50 3DP per block.

There are no checks if the pool is suspended in any of the MiningPool pallet's calls, or in the pool block reward distribution

After the node running.

gagein@gagein-desktop:~/3DP$ ./target/release/poscan-consensus --base-path ~/3dp-chain/ --chain mainnetSpecRaw.json --name gagein --validator --telemetry-url "wss://submit.telemetry.3dpscan.io/submit 0" --author 0x6274c90adbfc454a4211af91abfef1eb9ffe3bec01d548c0b0ec89c4a65f6b0f --threads 2 --no-mdns

2023-11-06 10:38:30 〽️ Prometheus exporter started at 127.0.0.1:9615
2023-11-06 10:38:31 🔍 Discovered new external address for our node: /ip4/121.144.209.220/tcp/30333/p2p/12D3KooWSiJ3RET8wPmVLsXxkzeAopd47PAb9FpYLaD2kDS5Gh8F

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

Version: 3.1.0-79caf1b-x86_64-linux-gnu

0: sp_panic_handler::set::{{closure}}
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn>::call
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1999:9
std::panicking::rust_panic_with_hook
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:695:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:582:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/sys_common/backtrace.rs:151:18
4: rust_begin_unwind
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/panicking.rs:578:5
5: core::panicking::panic_fmt
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/panicking.rs:67:14
6: core::panicking::panic_bounds_check
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/core/src/panicking.rs:162:5
7: p3d::algo_grid::get_contour
8: p3d::p3d_process_n
9: poscan_algo::get_obj_hashes_n
10: poscan_algo::get_obj_hashes
11: <poscan_grid2d::PoscanAlgorithm as sc_consensus_poscan::PowAlgorithm>::verify
12: <sc_consensus_poscan::PowBlockImport<B,I,C,S,Algorithm,CAW,CIDP> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
13: <alloc::boxed::Box<dyn sc_consensus::block_import::BlockImport+Error = sp_consensus::error::Error+Transaction = Transaction+core::marker::Sync+core::marker::Send> as sc_consensus::block_import::BlockImport>::import_block::{{closure}}
14: <&mut F as core::future::future::Future>::poll
15: sc_consensus::import_queue::basic_queue::BlockImportWorker::new::{{closure}}
16: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
17: <sc_service::task_manager::prometheus_future::PrometheusFuture as core::future::future::Future>::poll
18: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
19: <tracing_futures::Instrumented as core::future::future::Future>::poll
20: tokio::park::thread::CachedParkThread::block_on
21: tokio::runtime::handle::Handle::block_on
22: <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll
23: <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
24: tokio::runtime::task::harness::Harness<T,S>::poll
25: tokio::runtime::blocking::pool::Inner::run
26: std::sys_common::backtrace::__rust_begin_short_backtrace
27: core::ops::function::FnOnce::call_once{{vtable.shim}}
28: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1985:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/alloc/src/boxed.rs:1985:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/521f4dae1bdf7fe9cf9436ecef9ee7c7442708bf/library/std/src/sys/unix/thread.rs:108:17
29: start_thread
at /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8
30: clone
at /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

https://github.com/3Dpass/3DP/issues

Difficulty number doesn't change while block time is reducing below the target time.

Form set of Grandpa validators from miners that has been mined 100 blocks back (history depth) and endow them vote rights for the longest chain rule and best block. Change set of validators for each new block.

Motivation

According to the White Paper, we have to implement the Proof of Scan consensus and mining rules into the NODE.

Suggested Solution

Here is the rules:

1. New block time: 1 block per 6 seconds
2. Each 243000 blocks there is a difficulty step up involving “+0” requirement to be added at the front of HASH IDs. So, in order to create a new block after “climbing” over the step and get rewarded, someone has to pick up a unique 3D object (or just its 3D model) the Hash ID of which would include one more zero at the front. HASH ID example, from the genesis bloc to bloc number 243000:
   “090ae6b23e2192fa4c2fb40cddad6e8537e2b437c49ff9fb227cf32c4e4085fc”;

from block number 243001 to 486000:
“008cfda2b4811bf2ff1fe3ab92b38e64fc134d98c3dc8764eb8641a477b77a47”,

from block number 3402001 to 3645000:
“00000000000000f2ff1fe3abr6bt8e64fc134d98c3dc8764eb8641aff7b7sa4f”, etc.

Note that neither of these rules touches the objects published not in the reason of getting
mining rewards. So, miners have to strict the rules but the other users don’t. They might
publish any objects they want, of course, being charged 3DP for the validation service.
Ones new block is produced it’s getting waited for confirmations from validators. The
block reaches maturity according to GRANDPA protocol.

Alternatives

No alternatives

Additional Information

See more details in White Paper

Create a mining pool trait that would allow a number of devices to get connected to one Node running in a pool mode. Mining rewards are to divide among all the miners provided useful calculations to the pool.

Motivation

In order to gain liquidity 3DP needs to be added to the popular DEXes like Uniswap, the most of which represent L2 protocols based on Ethereum blockchain.

Suggested Solution

We should build a cross-chain bridge between 3DPass blockchain and Ethereum blockchan and add 3DP coin to the most popular DEXes

Alternatives

We can also consider Polkadex in addition

Additional Information

Research is required

Make every session change at unpredictable block number.

If any equivocation report received by the node, then the following is required:

1. Kick off the validator providing equivocation from the validator set
2. Slash penalties in amount of 40 000 P3D and transfer them to the Treasury pot

Increase the complexity of the generated 3D model. As there are more and more 3D models, the prompt ">>> duplicate hashes found more and more frequently.

671.7 Compiling pallet-conviction-voting v4.0.0-dev (https://github.com/paritytech/substrate?rev=b0777b4c7f7#b0777b4c)
1672.1 Compiling poscan-algo v3.0.0 (/app/consensus/poscan_algo)
1672.5 Compiling poscan-api v3.0.0 (/app/traits/poscan)
1672.5 error[E0599]: no method named is_finished found for struct JoinHandle in the current scope
1672.5 --> consensus/poscan_algo/src/lib.rs:164:15
1672.5 |
1672.5 164 | if handler.is_finished() {
1672.5 | ^^^^^^^^^^^ method not found in JoinHandle<(std::time::Duration, std::vec::Vec<sp_core::H256>)>
1672.5
1672.6 For more information about this error, try rustc --explain E0599.
1672.6 error: could not compile poscan-algo due to previous error
1672.6 warning: build failed, waiting for other jobs to finish...
1711.2 error: build failed

the lastest version

This happens during the mainnet launch.

Reproduce

At block 0, node start smoothly.

At block about 3, node crashed.
During the mainnet launch, dev started to run miner, and a fresh node just crashed. After empty db, tried to start the node again, same error message will appear. More than one miners posted the same error message. This could be an issue.

Rejoin the chain at around block 20.

It seems to be some edge cases.

Error message for the record

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

Version: 3.0.0-bd18d6a-x86_64-linux-gnu

   0: sp_panic_handler::set::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:702:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
   4: rust_begin_unwind
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
   5: core::panicking::panic_fmt
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
   6: core::panicking::panic_display
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:72:5
   7: core::panicking::panic_str
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:56:5
   8: core::option::expect_failed
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/option.rs:1874:5
   9: p3d::polyline::GenPolyLines::select_top
  10: p3d::algo_grid::find_top_std
  11: p3d::p3d_process
  12: poscan_grid2d::get_obj_hashes
  13: <poscan_grid2d::PoscanAlgorithm<C> as sc_consensus_poscan::PowAlgorithm<B>>::verify
  14: <sc_consensus_poscan::PowBlockImport<B,I,C,S,Algorithm,CAW,CIDP> as sc_consensus::block_import::BlockImport<B>>::import_block::{{closure}}
  15: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  17: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  19: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
  20: <sc_service::task_manager::prometheus_future::PrometheusFuture<T> as core::future::future::Future>::poll
  21: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
  22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  23: std::thread::local::LocalKey<T>::with
  24: tokio::park::thread::CachedParkThread::block_on
  25: tokio::runtime::handle::Handle::block_on
  26: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  27: tokio::runtime::task::harness::Harness<T,S>::poll
  28: tokio::runtime::blocking::pool::Inner::run
  29: std::sys_common::backtrace::__rust_begin_short_backtrace
  30: core::ops::function::FnOnce::call_once{{vtable.shim}}
  31: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys/unix/thread.rs:108:17
  32: start_thread
             at /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8
  33: clone
             at /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 'tokio-runtime-worker' panicked at 'Out of bounds access', /home/ben/.cargo/git/checkouts/p3d-675c372166b26a37/ac87950/src/polyline.rs:186

This is a bug. Please report it at:

        https://github.com/substrate-developer-hub/recipes/issues

This allows you to mine by only bruteforcing the poscan hash and submitting an unrelated object along with it, simplifying the task to just a single sha3

This can be fixed by checking it in

like

let dh = DoubleHash { pre_hash: *pre_hash, obj_hash: poscan_data.hashes[0] };
if dh.calc_hash() != seal.poscan_hash {
	info!(">>> verify: dh.calc_hash() != seal.poscan_hash");
	return Ok(false);
}

Set up constants for all the maiinet node's pallets

Forming up the chainspec file for the mainnet

Motivation

In order to ensure of working the NODE stand alone without GUI, there has to be the RPC command to submit 3D objects on the network.

Suggested Solution

A new additional command has to be added on top of the existing RPC ones.

When you are trying to send 3dPt to anyone, the error pops up.

Some Nodes are getting stuck at the certain height and falling behind the others. They would never catch up with the network and would never be up to date. In the other case, the Node just joined can not start syncing at all.

Activate --threads <number of threads> which allows to specify certain amount of threads used for mining.