consensus

问题 I am trying to run consensus clustering using M3C library in R. My dataset contains 451 samples and ~2500 genes. The row names are the ENTREZ IDs (numeric values) of the genes. I have crosschecked the dataset using "any(duplicated(colnames(MyData)))" command to make sure that there is no duplicate entries in the row names. I ran the following command to perform the consensus clustering using M3C library: res <- M3C(MyData, cores=8, seed = 123, des = annotation, removeplots = TRUE,

问题 What can happen if two proposals are issued with the same ProposalId? It shouldn't create any problem if they have the same value. But what about different values? I can work out a scenario where it risks liveness at the time of failure, but would it create any problem for the protocol's safety? 回答1: It's a nice idea because it would ease an annoying design requirement for a practical system: designing a scheme to ensure proposers have different, yet increasing round numbers. It doesn't work,

问题 I'm trying to use Paxos to maintain consensus between nodes on a file that is around 50MB in size, and constantly being modified at individual nodes. I'm running into issues of practicality. Requirements: Sync a 50MB+ file across hundreds of nodes Have changes to this file, which can be made from any node, and aren't likely to directly compete with each other, propagated across the network in a few seconds at most New nodes that join the network can within a few minutes (<1 hour) build up the

问题 I've been digging into some of the most used consensus algorithms in permissioned blockchains and I got stuck. I understood that BFT (Byzantine Fault Tolerance) is a property of some algorithms and pBFT is an algorithm itself. Is that right? This rule that 2/3 of the nodes in the network are enough to reach consensus, is it for all BFT algorithms or just pBFT? Also what is the difference between Byzantine Agreement and BFT? If you could provide a reliable source of information, I'd be

问题 What exactly are the practical consequences of missing consensus on a Kubernetes cluster? Or in other words: which functions on a Kubernetes cluster require consensus? What will work, what won't work? For example (and really only for example): will existing pods keep running? can pods still be scaled horizontally? Example scenario: A cluster with two nodes loses one node. No consensus possible. 回答1: Consensus is fundamental to etcd - the distributed database that Kubernetes is built upon.

问题 I want to use Hyperledger Fabric. But I need a special consensus algorithm. I have the concept ready but no idea how to get it implemented in Fabric. The documentation says: A consensus plugin needs to implement the Consenter and Chain interfaces defined in the consensus package. There are two plugins built against these interfaces already: solo and kafka. You can study them to take cues for your own implementation. The ordering service code can be found under the orderer package. First

问题 This question frequently comes up in conversations: When a Corda transaction is sent to a non-validating notary service for finalisation, what can the notary service see and deduce about the world? 回答1: Before sending a transaction to a non-validating notary, it is filtered as follows: stx.buildFilteredTransaction(Predicate { it is StateRef || it is TimeWindow || it == notaryParty }) (see NotaryFlow.kt in the main Corda repo). This means that the non-validating notary will only see: Any

问题 This is related to Hyperledger fabric v1.0 network topology. From the example, configtx.yaml contains following definitions: Profiles: TwoOrgsOrdererGenesis: Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2 TwoOrgsChannel: Consortium: SampleConsortium Application: <<: *ApplicationDefaults Organizations: - *Org1 - *Org2 There are two main sections. TwoOrgsOrdererGenesis This defines the orderer service and the genesis

问题 After reading paxos and raft paper, I have following confusion: paxos paper only describe consensus on single log entry, which is equivalent the leader election part of the raft algorithm. What's the advantage of paxos's approach over the simple random timeout approach in raft's leader election? 回答1: It is a common misconception that the original Paxos papers don't use a stable leader. In Paxos Made Simple on page 6 in the section entitled “The Implementation” Lamport wrote: The algorithm

问题 I am learning Paxos algorithm (http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf) and there is one point I do not understand. We know that events follow a timely order, and it happens when, say, events 1-5 and 10 are decided, but 6-9 and 11 thereafter are not yet. In the paper above, it says we simply fill in the gap between 6-9 with no-op values, and simply record new events from 11 and on. So in this case, since event 10 is already recorded, we know some kinds of