BitShares Forum
Main => General Discussion => Topic started by: bytemaster on September 08, 2015, 09:55:55 pm
-
Would like to introduce a new network protocol that should help keep witnesses in sync even during high traffic periods. It is implemented entirely in JavaScript using Node.js
First step is to set up a witness node like normal, only without giving it any P2P seed nodes.
./witness_node --rpc-endpoint "0.0.0.0:8090" --genesis-json aug-31-testnet-genesis.json
Checkout this repository:
https://github.com/cryptonomex/graphene-ui
cd dl; npm install
cd ../relay; npm install
./nodejs ./bootstrap.js config.js
Edit config.js to look like:
module.exports = {
api_host: 'localhost',
api_port: 8090,
upstream : 'ws://104.236.51.238:1778',
listen_port: 1779
}
The code is relatively simple and could probably be easily improved upon by any members on this forum who would like to take a stab at it.
I would like to see all witnesses on the test network use this code to connect rather than the P2P code we currently have.
There are known bugs in the Javascript code, but hopefully there are MANY more people around who are able to fix them and it is much easier to understand what is happening.
Thanks!
-
The idea behind this protocol is to establish a hierarchical communication tree where new transactions and blocks flow up to the root node and are then broadcast down through all the peers in the same order.
Under this approach there should be no forks and a block is only missed if a leaf witness is unable to get their block propagated to the root of the tree and down to the next witness within the block interval. In this event then a witness will miss their turn but the network should go on.
Additionally, all witnesses should produce blocks with transactions in the exact same order. Any witness that reorders transactions from the order in which they reached the root node will be very obvious.
-
It looks like several of you have connected and synced via this method. Feedback appreciated.
-
I just got it to connect. Syncing now.
-
So witnesses can run this protocol in addition to the block producing node?
-
It seemed to take longer to sync the blockchain running the new protocol. I'll have to time it when I get home from work.
-
which version should use for graphene?
I have got the error message from nodejs
!!! GrapheneApi error: broadcast_block [ { previous: '0001d8b2649ef6740ee31c74fd40e0e226b2e799',
timestamp: '2015-09-08T23:57:00',
witness: '1.6.76',
transaction_merkle_root: '0000000000000000000000000000000000000000',
extensions: [],
witness_signature: '1f1c2b31337dd65c646b972c47546a5a89d638c7ce9d03e993a713654af15a31be68bcd628cc4ffa72e86b9b09910d7c0c5c4b08e993c7d4d9391752b6300de6a5',
transactions: [] } ] { code: 1,
message: '10 assert_exception: Assert Exception\nitr != _by_name.end(): no method with name \'broadcast_block\'\n {"name":"broadcast_block","api":[["broadcast_transaction",0],["broadcast_transaction_with_callback",1]]}\n th_a api_connection.hpp:84 call',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object] ] } }
on UpstreamBlock error: { code: 1,
message: '10 assert_exception: Assert Exception\nitr != _by_name.end(): no method with name \'broadcast_block\'\n {"name":"broadcast_block","api":[["broadcast_transaction",0],["broadcast_transaction_with_callback",1]]}\n th_a api_connection.hpp:84 call',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object] ] } }
-
My witness is up and producing blocks using the jscript method. I was getting this error message for a while, but it has stopped now that the blocks have caught up.
Also I think I built from commit a748883fed08a73afaec647e2e8827d07ca3c163 (still learning git, used "git show" in graphene directory)
!!! GrapheneApi error: broadcast_block [ { previous: '0001d8a6de1024e6b4a7105304cd54fc1504c300',
timestamp: '2015-09-08T23:55:35',
witness: '1.6.51',
transaction_merkle_root: '0000000000000000000000000000000000000000',
extensions: [],
witness_signature: '1f427c6e912ce2fcd712baf356e37fe1bc5f6b09736fcb500bda3d73450d4119ad442af6b640182618da8095a0a6cdb12aa7e5f42ab029c0ca7e00f8910336318c',
transactions: [] } ] { code: 1,
message: '10 assert_exception: Assert Exception\nitem->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old\n {"item->num":120999,"head":121012,"max_size":13}\n th_a fork_database.cpp:70 _push_block\n\n {"new_block":{"previous":"0001d8a6de1024e6b4a7105304cd54fc1504c300","timestamp":"2015-09-08T23:55:35","witness":"1.6.51","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f427c6e912ce2fcd712baf356e37fe1bc5f6b09736fcb500bda3d73450d4119ad442af6b640182618da8095a0a6cdb12aa7e5f42ab029c0ca7e00f8910336318c","transactions":[]}}\n th_a db_block.cpp:176 _push_block',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object], [Object] ] } }
on UpstreamBlock error: { code: 1,
message: '10 assert_exception: Assert Exception\nitem->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old\n {"item->num":120999,"head":121012,"max_size":13}\n th_a fork_database.cpp:70 _push_block\n\n {"new_block":{"previous":"0001d8a6de1024e6b4a7105304cd54fc1504c300","timestamp":"2015-09-08T23:55:35","witness":"1.6.51","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f427c6e912ce2fcd712baf356e37fe1bc5f6b09736fcb500bda3d73450d4119ad442af6b640182618da8095a0a6cdb12aa7e5f42ab029c0ca7e00f8910336318c","transactions":[]}}\n th_a db_block.cpp:176 _push_block',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object], [Object] ] } }
-
which version should use for graphene?
I have got the error message from nodejs
!!! GrapheneApi error: broadcast_block [ { previous: '0001d8b2649ef6740ee31c74fd40e0e226b2e799',
timestamp: '2015-09-08T23:57:00',
witness: '1.6.76',
transaction_merkle_root: '0000000000000000000000000000000000000000',
extensions: [],
witness_signature: '1f1c2b31337dd65c646b972c47546a5a89d638c7ce9d03e993a713654af15a31be68bcd628cc4ffa72e86b9b09910d7c0c5c4b08e993c7d4d9391752b6300de6a5',
transactions: [] } ] { code: 1,
message: '10 assert_exception: Assert Exception\nitr != _by_name.end(): no method with name \'broadcast_block\'\n {"name":"broadcast_block","api":[["broadcast_transaction",0],["broadcast_transaction_with_callback",1]]}\n th_a api_connection.hpp:84 call',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object] ] } }
on UpstreamBlock error: { code: 1,
message: '10 assert_exception: Assert Exception\nitr != _by_name.end(): no method with name \'broadcast_block\'\n {"name":"broadcast_block","api":[["broadcast_transaction",0],["broadcast_transaction_with_callback",1]]}\n th_a api_connection.hpp:84 call',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object] ] } }
nodejs connected but I am getting the same errors.
-
not sure if this helps but I ran
nodejs bootstrap.js from the /graphene-ui/relay directory
-
Looks like I'm in sync, but I'm not producing blocks.
-
There are errors with "cd ../relay;npm install", but it can run.
Logs are crazy scrolling, lots of "Assertion Exception: failed to push a block that is too old" or so, but it's catching up.
OK, I'm in sync now.
-
From the logs I can see I generated a block but it seems didn't get included in the main chain.
//Edit: looks like it's because the correct block came later.
2015-09-09T04:28:03 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772882997063 next_second:
2015-09-09T04:28:04 witness.cpp:146
2015-09-09T04:28:04 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
witness.cpp:182
2015-09-09T04:28:04 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772883997067 next_second:
2015-09-09T04:28:05 witness.cpp:146
2015-09-09T04:28:05 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:05 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772884997090 next_second:
2015-09-09T04:28:06 witness.cpp:146
2015-09-09T04:28:06 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:06 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772885997094 next_second:
2015-09-09T04:28:07 witness.cpp:146
2015-09-09T04:28:07 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:07 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772886997099 next_second:
2015-09-09T04:28:08 witness.cpp:146
2015-09-09T04:28:08 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:08 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772887997102 next_second:
2015-09-09T04:28:09 witness.cpp:146
2015-09-09T04:28:09 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:09 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772888997099 next_second:
2015-09-09T04:28:10 witness.cpp:146
2015-09-09T04:28:10 th_a:Witness Block Production push_block ] new_block.block_num(): 123451 new_block.id(): 0001e23b1e939a70bd340efc1e5c5dcf484f8975 db_block.cpp:86
2015-09-09T04:28:10 th_a:Witness Block Production block_production_loo ] Generated block #123451 with timestamp 2015-09-09T04:28:10 at
time 2015-09-09T04:28:10 witness.cpp:173
2015-09-09T04:28:10 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772889998632 next_second:
2015-09-09T04:28:11 witness.cpp:146
2015-09-09T04:28:10 th_a:? push_block ] new_block.block_num(): 123451 new_block.id(): 0001e23b1e939a70bd340ef
c1e5c5dcf484f8975 db_block.cpp:86
2015-09-09T04:28:11 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
witness.cpp:182
2015-09-09T04:28:11 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772890997069 next_second:
2015-09-09T04:28:12 witness.cpp:146
2015-09-09T04:28:12 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
witness.cpp:182
2015-09-09T04:28:12 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772891997068 next_second:
2015-09-09T04:28:13 witness.cpp:146
2015-09-09T04:28:13 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
witness.cpp:182
2015-09-09T04:28:13 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772892997044 next_second:
2015-09-09T04:28:14 witness.cpp:146
2015-09-09T04:28:14 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
witness.cpp:182
2015-09-09T04:28:14 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772893997052 next_second:
2015-09-09T04:28:15 witness.cpp:146
2015-09-09T04:28:15 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
witness.cpp:179
2015-09-09T04:28:15 th_a:Witness Block Production schedule_production_ ] now.time_since_epoch().count(): 1441772894997099 next_second:
2015-09-09T04:28:16 witness.cpp:146
2015-09-09T04:28:15 th_a:? push_block ] new_block.block_num(): 123451 new_block.id(): 0001e23b7b7768510491e30c156fe168e9bcc160 db_block.cpp:86
get_block 123451
{
"previous": "0001e23aefb943aced06ea1055b06b4520f09751",
"timestamp": "2015-09-09T04:28:15",
"witness": "1.6.65",
"transaction_merkle_root": "0000000000000000000000000000000000000000",
"extensions": [],
"witness_signature": "1f4eef9dda295a5eeaf0f3f2feb11f00ee65cbbb8e507002d6fcd12527cb23a1142049714b5a9ebdd24fc59fca4c3008c857a3fd90197bb8ea5dae39ff170f5eaa",
"transactions": [],
"block_id": "0001e23b7b7768510491e30c156fe168e9bcc160",
"signing_key": "GPH7eYmrY2wJq8fn8gRSN3eXWSgMoyZYFPYRD6F5uhwNuwzDuFCYE"
}
-
Produced another block and didn't get included in the main chain again.
And again.
No such issue with the old p2p protocol.
What's wrong?
-
It's stuck now.
UNABLE TO FIND BLOCK: 123657
-
Got this error with enable-stale-production option
!!! GrapheneApi error: broadcast_transaction [ { ref_block_num: 58120,
ref_block_prefix: 2588741439,
expiration: '2015-09-09T04:52:43',
operations: [ [Object] ],
extensions: [],
signatures: [ '1f110b687d6506e797df05dcbb00dda42185c34e630a4dd178829948eb0580a63c6480c22
4f230b2b36950611b130b03f2d5798147149ca7eb8bf1bc75166195aa' ] } ] { code: 1,
message: '10 assert_exception: Assert Exception\ntrx.ref_block_prefix == tapos_block_summa
ry.block_id._hash[1]: \n {}\n th_a db_block.cpp:518 _apply_transaction\n\n {"trx":
{"ref_block_num":58120,"ref_block_prefix":2588741439,"expiration":"2015-09-09T04:52:43","ope
rations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.22310
","amount":{"amount":1,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":[
"1f110b687d6506e797df05dcbb00dda42185c34e630a4dd178829948eb0580a63c6480c224f230b2b36950611b1
30b03f2d5798147149ca7eb8bf1bc75166195aa"]}}\n th_a db_block.cpp:553 _apply_transaction\n
\n {"trx":{"ref_block_num":58120,"ref_block_prefix":2588741439,"expiration":"2015-09-09T0
4:52:43","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","t
o":"1.2.22310","amount":{"amount":1,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"
signatures":["1f110b687d6506e797df05dcbb00dda42185c34e630a4dd178829948eb0580a63c6480c224f230
b2b36950611b130b03f2d5798147149ca7eb8bf1bc75166195aa"]}}\n th_a db_block.cpp:195 push_tr
ansaction',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object], [Object], [Object] ] } }
-
It's stuck now.
UNABLE TO FIND BLOCK: 123657
Me too
info
{
"head_block_num": 123660,
"head_block_id": "0001e30c380cf6e155c388b77b0fc05862ce20f9",
"head_block_age": "32 minutes old",
"next_maintenance_time": "29 minutes ago",
"chain_id": "ecbde738ba0b319cb4d266e613b200d010da8b37313c20aec03f9c8e2d9b35e3",
"participation": "42.18750000000000000",
"active_witnesses": [
-
npm install forever
./node_modules/forever/bin/forever start bootstrap.js
to have it restarted automatically on crashes
-
I'm getting this error while trying to get synced up:
on UpstreamBlock error: { code: 1,
message: '10 assert_exception: Assert Exception\nitem->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old\n {"item->num":13876,"head":72389,"max_size":12}\n th_a fork_database.cpp:70 _push_block\n\n {"new_block":{"previous":"00003633640d0136407e06e19c7f2c5bdd69e5d5","timestamp":"2015-09-01T16:58:00","witness":"1.6.11","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f05778a72f0b9f3933940bb92ba45d0ca102e3b199b66711176f9193028e85cb75588f5307e21ea40e887a54b801958deba5a55e36121641ecd447b071425afb8","transactions":[]}}\n th_a db_block.cpp:176 _push_block',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object], [Object] ] } }
!!! GrapheneApi error: broadcast_block [ { previous: '00003634b03a696314a900b852b58c9f3055411b',
timestamp: '2015-09-01T16:58:05',
witness: '1.6.88',
transaction_merkle_root: '0000000000000000000000000000000000000000',
extensions: [],
witness_signature: '200299652ccc50ab1a1ea7f6d3c9dc766481e0942b615d5d5a6fe0810d3f09129c305abf31e0e9db05c61adea40c9836cbb051819e930eab291067e61cb5d101c2',
transactions: [] } ] { code: 1,
message: '10 assert_exception: Assert Exception\nitem->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old\n {"item->num":13877,"head":72389,"max_size":12}\n th_a fork_database.cpp:70 _push_block\n\n {"new_block":{"previous":"00003634b03a696314a900b852b58c9f3055411b","timestamp":"2015-09-01T16:58:05","witness":"1.6.88","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"200299652ccc50ab1a1ea7f6d3c9dc766481e0942b615d5d5a6fe0810d3f09129c305abf31e0e9db05c61adea40c9836cbb051819e930eab291067e61cb5d101c2","transactions":[]}}\n th_a db_block.cpp:176 _push_block',
data:
{ code: 10,
name: 'assert_exception',
message: 'Assert Exception',
stack: [ [Object], [Object] ] } }
Strangely I'm seeing this in the witness_node output:
712883ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119327 new_block.id(): 0001d21f87bd22853130326091e5efb1faa8e592
712886ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119328 new_block.id(): 0001d2204fff78f7af81b57046e291dcef1fe3aa
712909ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15439 new_block.id(): 00003c4f5b29ca50cd0fa565a8bc75f5cfe868a5
712909ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15440 new_block.id(): 00003c5070ef8259c41a6839bf6be8869e1162d0
712910ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15441 new_block.id(): 00003c5152cfd4c179622e102aa6bd16e500d601
712911ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15442 new_block.id(): 00003c5296d802f94f7f881c6d8a72caeecb1cd5
712912ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15443 new_block.id(): 00003c5391bc89741c6213b5cb84d88bd44e7b23
712912ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15444 new_block.id(): 00003c5423e90c1df272983990a7802b174c1969
712913ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15445 new_block.id(): 00003c5579120007b200eb409f080a2bded5b984
712914ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15446 new_block.id(): 00003c56964d726fd5d3e1b0f0259f33e9f025af
712914ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15447 new_block.id(): 00003c57e1e057bee2284b9c7b0dc7352c20e5ac
712915ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15448 new_block.id(): 00003c58714d00006a6949da7339934cbdcf8d16
712915ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15449 new_block.id(): 00003c59700747724b5fb2f432af204124be9b1e
712916ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15450 new_block.id(): 00003c5a6122e27542e9787b1d4a394dd74ebd73
712917ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15451 new_block.id(): 00003c5b15c482cb6ed742549847a6ee8d355b9e
712918ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15452 new_block.id(): 00003c5c3f23330815f76136305b06b9f2a8d6fe
712918ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15453 new_block.id(): 00003c5d6df2b553f55d1c7f16dcd6fa281109aa
712919ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 15454 new_block.id(): 00003c5ecfa9942c7d7ddbc3201e29eed79cf3dc
712922ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119329 new_block.id(): 0001d221110e00f5907bcac85bc30883840d828a
712925ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119330 new_block.id(): 0001d2228dfea95ab84a148f99b532d97c6ac253
712929ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119331 new_block.id(): 0001d22328872cd7f4114498c3b86ab708d0e262
712932ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119332 new_block.id(): 0001d22480b153ae3b5de932e9a0efefd83c6a8e
712936ms th_a db_block.cpp:86 push_block ] new_block.block_num(): 119333 new_block.id(): 0001d225daa0b9825becfd3c4ff6ba9cae738903
If I stop the the relay server syncing stops on the witness_node, despite all the errors I'm seeing related to pushing blocks that are too old.
-
The idea behind this protocol is to establish a hierarchical communication tree where new transactions and blocks flow up to the root node and are then broadcast down through all the peers in the same order.
Under this approach there should be no forks and a block is only missed if a leaf witness is unable to get their block propagated to the root of the tree and down to the next witness within the block interval. In this event then a witness will miss their turn but the network should go on.
Additionally, all witnesses should produce blocks with transactions in the exact same order. Any witness that reorders transactions from the order in which they reached the root node will be very obvious.
Are there docs for how this tree structure is created/maintained?
Also, since when does bytemaster write anything in javascript? =P
-
It's stuck now.
UNABLE TO FIND BLOCK: 123657
Me too
info
{
"head_block_num": 123660,
"head_block_id": "0001e30c380cf6e155c388b77b0fc05862ce20f9",
"head_block_age": "32 minutes old",
"next_maintenance_time": "29 minutes ago",
"chain_id": "ecbde738ba0b319cb4d266e613b200d010da8b37313c20aec03f9c8e2d9b35e3",
"participation": "42.18750000000000000",
"active_witnesses": [
Same result. Stuck.
{
"head_block_num": 123659,
"head_block_id": "0001e30bb947c35176dfe5271ccf504682ce0ed7",
"head_block_age": "3 hours old",
"next_maintenance_time": "3 hours ago",
"chain_id": "ecbde738ba0b319cb4d266e613b200d010da8b37313c20aec03f9c8e2d9b35e3",
"participation": "82.03125000000000000",
-
Got synced up to block 123659 but now I'm stuck.
-
Why doesn't this change the security model of the network? Who gets to be the root node? What if that node goes down?
-
Why doesn't this change the security model of the network? Who gets to be the root node? What if that node goes down?
I was wondering about this as well
The script is more like a proxy that reduces the load on the witness ... the P2P ports are opened and maintained (proxied to the witness) by the nodeJS script
-
Why doesn't this change the security model of the network? Who gets to be the root node? What if that node goes down?
I was wondering about this as well
The script is more like a proxy that reduces the load on the witness ... the P2P ports are opened and maintained (proxied to the witness) by the nodeJS script
If the network can fall back on peer-to-peer upon root failure. I think this should be fine.
-
If the network can fall back on peer-to-peer upon root failure. I think this should be fine.
What if the root is compromised and starts sending out transactions in an order which favours it?
-
If the network can fall back on peer-to-peer upon root failure. I think this should be fine.
What if the root is compromised and starts sending out transactions in an order which favours it?
Good question and a valid concern. Let BM explain the rationale.
-
Got stuck in same place overnight.
"head_block_num": 123659,
"head_block_id": "0001e30bae565a49fa6a29f751dadead994fd312",
"head_block_age": "7 hours old",
"next_maintenance_time": "7 hours ago",
"chain_id": "ecbde738ba0b319cb4d266e613b200d010da8b37313c20aec03f9c8e2d9b35e3",
"participation": "82.81250000000000000",
-
If the network can fall back on peer-to-peer upon root failure. I think this should be fine.
What if the root is compromised and starts sending out transactions in an order which favours it?
Good question and a valid concern. Let BM explain the rationale.
The idea is that the root node is "real time" and doesn't get an opportunity to buffer and reorder. Though technically it could. The witnesses would then decide whether or not they want to coordinate via a central service to provide higher reliability or whether they wish to remain P2P.
Now granted, the relay code was written in one day and still has some issues that need to be resolved. For example, if the root node goes on a temporary fork then all peers on the relay network get stuck.
JavaScript is easier to write / debug than C++ and more people around here can probably help improve it.
-
The idea is that the root node is "real time" and doesn't get an opportunity to buffer and reorder. Though technically it could. The witnesses would then decide whether or not they want to coordinate via a central service to provide higher reliability or whether they wish to remain P2P.
And how do they know the central service has not been compromised? How can they tell the difference between a poor network connection and a compromised service?
-
JavaScript is easier to write / debug than C++ and more people around here can probably help improve it.
Looks like a message parameter to "this.isKnownTransaction()" was left out here:
isKnownTransaction( message ) {
return this.known_trxsa.has(message) || this.known_trxsb.has(message)
}
addKnownTransaction( message ) {
if( !this.isKnownTransaction() )
{
this.known_trxsa.add(message)
return true;
}
return false
}
This would prevent transactions from being sent from the client to the upstream 'root' node. I created an issue in github...
I see the web socket keeps a list of its clients. I guess this means every client holds another client list just like the root node?
-
Are there docs for how this tree structure is created/maintained?
Also, since when does bytemaster write anything in javascript? =P
Good question ... Docs or even just a hint on how that might look.
Bytemaster took probably a week to learn JavaScript and basically another week to get a good overview of our entire web architecture. This was his contribution as a result, called the chain.js (https://github.com/cryptonomex/graphene-ui/blob/e4d3dab954b431d8cbab500d49ebbe5afac2e354/dl/src/api/chain.js). It has since been renamed to the ChainStore.js (https://github.com/cryptonomex/graphene-ui/blob/1863506f349dc76c95aa248ae2810920240a2718/dl/src/api/ChainStore.js).
-
Are there docs for how this tree structure is created/maintained?
Also, since when does bytemaster write anything in javascript? =P
Good question ... Docs or even just a hint on how that might look.
Bytemaster took probably a week to learn JavaScript and basically another week to get a good overview of our entire web architecture. This was his contribution as a result, called the chain.js (https://github.com/cryptonomex/graphene-ui/blob/e4d3dab954b431d8cbab500d49ebbe5afac2e354/dl/src/api/chain.js). It has since been renamed to the ChainStore.js (https://github.com/cryptonomex/graphene-ui/blob/1863506f349dc76c95aa248ae2810920240a2718/dl/src/api/ChainStore.js).
Lets just say that for all of the great things about C++, I have found I can develop faster in JavaScript and have come to appreciate the garbage collection and memory management. Though it is annoying not having type checking to catch simple errors like the one James identified above :)
I also like having one codebase rather than two :)
-
The idea is that the root node is "real time" and doesn't get an opportunity to buffer and reorder. Though technically it could. The witnesses would then decide whether or not they want to coordinate via a central service to provide higher reliability or whether they wish to remain P2P.
And how do they know the central service has not been compromised? How can they tell the difference between a poor network connection and a compromised service?
Could you have independent 3rd party services publish a merkle root hash for each new block? The entire chain you get from any independent central service has to hash all the way up to the root. I may be over-simplifying it, but that could validate everything...
-
Same here
Same result. Stuck.
{
"head_block_num": 123659,
"head_block_id": "0001e30bb947c35176dfe5271ccf504682ce0ed7",
"head_block_age": "3 hours old",
"next_maintenance_time": "3 hours ago",
"chain_id": "ecbde738ba0b319cb4d266e613b200d010da8b37313c20aec03f9c8e2d9b35e3",
"participation": "82.03125000000000000",
-
Could you have independent 3rd party services publish a merkle root hash for each new block? The entire chain you get from any independent central service has to hash all the way up to the root. I may be over-simplifying it, but that could validate everything...
Why not just through away all the clients completely and have a plain, centralised bitshares service? I don't see the point of p2p at all when you're talking about using centralised validation service.
-
Wackou and I will be getting together on mumble tomorrow at 3PM CDT to discuss additional nodes on the backbone approach he has described here: http://digitalgaia.io/backbone.html (http://digitalgaia.io/backbone.html).
BM, have you read Wackou's info about his backbone approach and DDOS protection scheme via backbone node proxies? It directly addresses the issue of security and more importantly for graphene connection latency.
I can't help but feel there is major overlap / reinvention of our plans from this thread.
If I am misunderstanding the intent of this thread I apologize, as I have not been able to stay in touch as well as usual due to personal issues.
-
Is it working now? I cannot sync using this thing.
-
Is it working now? I cannot sync using this thing.
Not working for me.. I switched to the original p2p protocol.
-
The main server ran out of disk space :(
-
Are there docs for how this tree structure is created/maintained?
Also, since when does bytemaster write anything in javascript? =P
Good question ... Docs or even just a hint on how that might look.
Bytemaster took probably a week to learn JavaScript and basically another week to get a good overview of our entire web architecture. This was his contribution as a result, called the chain.js (https://github.com/cryptonomex/graphene-ui/blob/e4d3dab954b431d8cbab500d49ebbe5afac2e354/dl/src/api/chain.js). It has since been renamed to the ChainStore.js (https://github.com/cryptonomex/graphene-ui/blob/1863506f349dc76c95aa248ae2810920240a2718/dl/src/api/ChainStore.js).
Lets just say that for all of the great things about C++, I have found I can develop faster in JavaScript and have come to appreciate the garbage collection and memory management. Though it is annoying not having type checking to catch simple errors like the one James identified above :)
I also like having one codebase rather than two :)
You could check TypeScript.
http://www.typescriptlang.org/
Node.js example
https://github.com/Microsoft/TypeScriptSamples/tree/master/imageboard
-
The main server ran out of disk space :(
Awww.... :'(
-
@bytemaster please let us know when the node is back, so we can keep testing.
-
I started doing some asynchronous programming in node and learning javascript this last year. this code is an abomination. I understood none of it. But will give BM some slack, I am just a novice. I have started reading ES6... so maybe I like Promises... I'll see about 'class'. A networking protocol in javascript intrigues me so I am going to try and understand it.