Hot answers tagged

9

I'll take a try to explain in simpler terms. But first I assume you understand that Quorum Slices are to help a Stellar node do the validation. Stellar is all about trust (validators). After all, when you have to trust somebody, you'd trust the reputated nodes, rather than a random stranger node on the internet. You can imagine Quorum as a list of ...


4

There are two distinct phases/sub-protocols with different purpose in SCP: the ballot protocol ensures that if a quorum agrees to something, all nodes will agree to the same thing; the nomination protocol is there to pick “interesting values” to feed into the ballot protocol. An interesting value is constructed such that: it converges over time, values ...


4

If you look at the stellar-core codebase, under the HerderSCPDriver's validateValueHelper function, there is this code snippet: // Check closeTime (not too old) if (b.closeTime <= lastCloseTime) { return SCPDriver::kInvalidValue; } // Check closeTime (not too far in future) uint64_t timeNow = mApp.timeNow(); if (b....


4

Each node has it's own unique NODE_SEED which is used for messages signing. It can be set in the config file. The seed used for generating the public key this node will be identified with in SCP (that's a node ID you mentioned). If you don't specify the NODE_SEED parameter explicitly, it will be generated randomly on each startup. To generate a new, ...


4

slot is simply a ledger number in Stellar implementation. Once previous ledger closed nodes start by proposing candidates for the next "slot" and then vote on it. Some relevant info can be found here key implementation details The Herder considers a ledger number to be a "slot" in the SCP protocol, and transaction set hashes (along with ...


4

The Stellar Consensus Protocol is a form of Byzantine agreement protocol. It is said to be Sybil-proof. It is discussed in page 3 of the Stellar Consensus Protocol official paper And I really can't explain better than the people who implemented it in this use case.


4

As a practical matter, SCP's asymptotic security follows from the fact that it depends only on digital signatures (and hash functions) for security, and that these can be tuned to resist arbitrarily powerful attackers. For example, you consider an attack in which every grain of sand on earth is a supercomputer attempting to break SCP a billion times per ...


4

This certainly deserves a more complete answer than I'm about to give, and hopefully someone can go ahead and give it -- but the root of it is that a node chooses (manually) which other notes to include in its quorum slices. Check out this nice article on the SCP and how quorum slices function: https://etale-cohomology.github.io/stellar-tutorials/blog1.html ...


4

Each node synchronizes the state with the quorum set, so archives tampering won't work. The node will be unable to catch up with SCP quorum if the local state differs from the quorum-approved state. Nobody can modify a single archive file without messing up the whole archive because each ledger contains hash of the previous ledger and they are validated ...


4

The tricky part is that the timer for the nomination rounds of the SCP protocol starts five seconds after the previous slot's nomination protocol has ended. If you want to have an arbitrary delay between slots while waiting for a transaction, you may want to trigger the start of nomination from something other than the previous round. However, the only ...


3

I found method which returns the expected ledger closing time, std::chrono::seconds Config::getExpectedLedgerCloseTime() const { if (ARTIFICIALLY_SET_CLOSE_TIME_FOR_TESTING) { return std::chrono::seconds{ARTIFICIALLY_SET_CLOSE_TIME_FOR_TESTING}; } if (ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING) { return std::chrono::...


3

This is by analogy with symmetric Byzantine agreement protocols (in which everyone has the same quorum slices). You need any two quorums to intersect at an honest node. If your threshold is 2/3 or lower then you need to proceed when 1/3 of nodes have failed. But if you divide nodes into three equal-sized groups A, B, and M, and M is bad, then A+M and B+M ...


3

Nodes rely on the fact that SCP messages are broadcasted to all peers on the network (for the most part); the number of peer to peer connections just increases the chances that the network as a whole is strongly connected (it's mostly randomly connected) which in turn pretty much guarantees that messages eventually reach all peers on the network. Note that ...


3

You're mixing up two completely different concepts here. One is about transaction finality, and the other is about resistance to sybil attacks. POW has probabilistic finality, since there's always the potential of a longer chain reverting your transaction. SCP has deterministic finality -- when a transaction is included in a ledger update, that's it. No ...


3

The function you linked to seems to be removing the transactions from a transaction set that have the lowest fees, until the set size equals 100. This corresponds with the documentation which states: Each Stellar node usually limits the number of transactions that it will propose to the network when a ledger closes. If too many transactions are submitted,...


3

Yes, Horizon waits for the transaction to be included into the ledger. SCP protocol implies immediate finality after the confirmation, so your transaction is 100% confirmed and included into the ledger once you receive the confirmation from Horizon. If it fails, Horizon returns specific error code. You don't need to track your transaction after submission or ...


2

If you run a stellar-core instance, it is possible to query the quorum set for any validator via an http request on port 11626: Here is the endpoint your would use: quorum /quorum?[node=NODE_ID][&compact=true] And here is a description from the docs on the Stellar website: returns information about the quorum for node NODE_ID (this node by ...


2

The SCPPrepare message conveys "vote commit ballot ". However, it does not convey "accept commit c" for any c, because if it accepts any commit message then it immediately proceeds to the COMMIT phase and issues SCPCommit instead of SCPPrepare messages. Of course, a node in the PREPARE phase could accept "commit c" for some ballot c after getting SCPCommit ...


2

SCP doesn't have any theoretical limits, since really all you need to agree on is a SHA-256 hash of an arbitrary-sized set of transactions. However, the Stellar validators vote to set a maximum number of transactions per block, which is currently at 50 transactions/block. To see this value, you can query horizon for the latest block header: $ curl 'https:/...


2

If you’re trying to build a 2 nodes setup it’s unlikely to work: the only safe way to run such a setup would be to have nodes that depend on each other (ie neither can go down) as otherwise you would allow each node to diverge from each other. For testing purpose you should use 1 node or more generally2*f+1 where f is the number of failures you want to ...


2

The Stellar Consensus Protocol is a type of federated Byzantine agreement protocol. So FBA is a broader category that includes SCP. There's a more recent peer-reviewed paper written for the SOSP that I personally find a bit easier to parse than the original white paper. Here's what it says: "Stellar introduces a new Byzantine agreement protocol, SCP (...


1

Having consulted my local expert, it appears that when I perform a partial catchup, the core retrieves the entire state of the blockchain, just not the entire transaction history of the blockchain. So: the core would still know every account in the blockchain the core would also be able to verify txs related to every account the core would just NOT be able ...


1

The protocol consists of exchanging digitally-signed messages bound to nodes' quorum slices. ( https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ ) The trusted nodeIds that you put in your quorum set VALIDATORS configuration are in fact public keys of the secret NODE_SEEDs from the opposing nodes.


1

A node can only be befouled if there exists an ill-behaved node befouling the node. This is only true if you have nominal quorum intersection. That's why so many of the theorems say "assume an FBAS with quorum intersection." More recent expositions of the protocol such as the recent SOSP paper get around this problem by defining a quorum as a set ...


1

So fixed this problem. My node1's get in history was not pointing to the node2's archive path. After setting them properly it worked. Node1's history configuration [HISTORY.local] get="cp /tmp/stellar-core/node02/history/vs/{0} {1}" put="cp {0} /tmp/stellar-core/node01/history/vs/{1}" mkdir="mkdir -p /tmp/stellar-core/node01/history/vs/{0}" Node2's ...


1

At this point, there are a bunch of small ways in which the internet draft is not wire compatible with stellar-core. The most important is that while multiple people have implemented SCP, there is only one implementation of the underlying overlay protocol, which has not been specified outside of the stellar-core implementation, and probably won't be, so ...


1

Yes. Stellar Development Foundation (SDF) maintains three validators, which you can find in this list of validators. If you include at least one of them in every quorum slice, you will stay in sync with SDF and hence very likely with the rest of the world. Down the line, however, other entities may come to be perceived as more important than SDF (e.g., ...


1

1) Do all nodes in stellar-network know about my transaction and decide whether to include it in the ledger or not? Or does the decision accept only the quorum to which I belong? Yes, all nodes decide, or rather whatever nodes you submit it to. A malformed transaction or one on an invalid account won't get forwarded, while a valid transaction will. But ...


1

I believe there are implementations either complete or in progress, but am not sure if any have been publicly released. If you want to implement SCP, I strongly recommend starting with the protocol specification draft rather than the whitepaper. Many of the people following the draft hang out on the IRTF Decentralized Internet Infrastructure list, so that ...


1

As per my understanding, the flow should be like this: SCP NOMINATION SCPNominate Vote x Accept x Confirm x BALLOTING SCPPrepare Vote prepare(b) Accept prepare(b) Confirm prepare(b)/Vote commit(b) SCPCommit Accept commit(b) ...


Only top voted, non community-wiki answers of a minimum length are eligible