BitShares Forum
Main => General Discussion => Topic started by: sfinder on June 30, 2014, 04:16:12 pm
-
hi BM, I am passing 2 suggestions from Chinese community based on the result of DPOS testing. please let me know if you need more detail information.
The first suggestion is to allow 2-10 delegates to race for the same block and the fastest one produce the block.
the 2nd suggestion is to use "EPaxos" for helping to resolve our forking issues due to limited bandwidth and slow hardware performance of our delegates .
Hi BM and Toast ,
2 programers from Chinese community would like to make a suggestion for you to use "EPaxos" for helping to resolve our forking issues due to limited bandwidth and slow hardware performance of our delegates .
https://github.com/efficient/epaxos
Iulian Moraru, David G. Andersen -- Carnegie Mellon University
EPaxos
What is EPaxos?
EPaxos is an efficient, leaderless replication protocol. The name stands for Egalitarian Paxos -- EPaxos is based on the Paxos consensus algorithm. As such, it can tolerate up to F concurrent replica failures with 2F+1 total replicas.
How does EPaxos differ from Paxos and other Paxos variants?
To function effectively as a replication protocol, Paxos has to rely on a stable leader replica (this optimization is known as Multi-Paxos). The leader can become a bottleneck for performance: it has to handle more messages than the other replicas, and remote clients have to contact the leader, thus experiencing higher latency. Other Paxos variants either also rely on a stable leader, or have a pre-established scheme that allows different replicas to take turns in proposing commands (such as Mencius). This latter scheme suffers from tight coupling of the performance of the system from that of every replica -- i.e., the system runs at the speed of the slowest replica.
EPaxos is an efficient, leaderless protocol. It provides strong consistency with optimal wide-area latency, perfect load-balancing across replicas (both in the local and the wide area), and constant availability for up to F failures. EPaxos also decouples the performance of the slowest replicas from that of the fastest, so it can better tolerate slow replicas than previous protocols.
How does EPaxos work?
We have an SOSP 2013 paper that describes EPaxos in detail.
A simpler, more straightforward explanation is coming here soon.
What is in this repository?
This repository contains the Go implementations of:
Egalitarian Paxos (EPaxos), a new distributed consensus algorithm based on Paxos EPaxos achieves three goals: (1) availability without interruption as long as a simple majority of replicas are reachable---its availability is not interrupted when replicas crash or fail to respond; (2) uniform load balancing across all replicas---no replicas experience higher load because they have special roles; and (3) optimal commit latency in the wide-area when tolerating one and two failures, under realistic conditions. Egalitarian Paxos is to our knowledge the first distributed consensus protocol to achieve all of these goals efficiently: requiring only a simple majority of replicas to be non-faulty, using a number of messages linear in the number of replicas to choose a command, and committing commands after just one communication round (one round trip) in the common case or after at most two rounds in any case.
(classic) Paxos
Mencius
Generalized Paxos
The struct marshaling and unmarshaling code was generated automatically using the tool available at: https://code.google.com/p/gobin-codegen/
The repository also contains a machine-readable (and model-checkable) specification of EPaxos in TLA+.
AUTHORS:
Iulian Moraru, David G. Andersen -- Carnegie Mellon University
Michael Kaminsky -- Intel Labs
EPAXOS 作者是Toast学校的。
硬件不足，软件补。赞赏这个设计，目前的网络体系架构并不适合网络货币的需求，需要在软件上做补偿设计。
是啊，这两天看了EPAXOS算法，这货=DPOS+现在BM正在搞得代表之间协议啊。如果BM能完成的质量高可以，还是分叉严重的话谁能帮忙给BM推荐参考一下这算法？哪位大侠能直接跟BM沟通。
https://github.com/efficient/epaxos
转hackfisher 或直接pm bm吧
-
+5%
-
How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus
-
How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus
The issue with forking is not because of slow systems or network problems. It is almost entirely due to implementation bugs. I am fairly certain we have narrowed it down to a blocking socket write that prevents other sockets from being sent data until a TCP timeout.
-
For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?
For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.
-
How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus
You sure ARE a crabby little patty! Notice how he doesn't even argue with you? Just answers your question while ignoring the bash?
Deserving of just a "little" respect crabby?
-
For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?
For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.
Thanks Bm/Toast. I have passed answers back to chinese board
-
For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?
For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.
Hi Toast , as you mentioned the size of block is around 512kb. I am wondering how many transactions can be included in a block? If our BTSX as busy as VISA then if we are still able to handle ? and what size of blockchain will be?
-
How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus
You sure ARE a crabby little patty! Notice how he doesn't even argue with you? Just answers your question while ignoring the bash?
Deserving of just a "little" respect crabby?
+1
Sent from my iPhone using Tapatalk
-
For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?
For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.
Hi Toast , as you mentioned the size of block is around 512kb. I am wondering how many transactions can be included in a block? If our BTSX as busy as VISA then if we are still able to handle ? and what size of blockchain will be?
Transactions are like 300 bytes, so about 60 transactions per second average at max volume for the initial chain. Of course since there will eventually be many chains there is lots of potential for chains with smaller transactions or faster blocks or bigger block sizes or what have you.
With current plan BTS X is main hub for BitUSD stability and "serious" user-issued assets. I imagine high-volume trades will be on another chain, like fiat currency exchange or altcoin exchange or whatever.