2

In Stellar, the transactions are stored in ledgers. Since the computation of current hash does not depend on previous hash (since its blockless), how can it be guaranteed that the data stored is true. The second question is about traversing to find the ledger state. To find an account details Do I need to traverse the stellar ledgers (like a link list) to find the last transaction details of an account or Do I directly query the account database and if its the latter case what is the guarantee that the database stored is the correct one ?

  • I guess it would be more accurate to posit "since it is chainless" as that's the property you're asking about. However, as user3188445 states the prior hash is in the ledger header, so it is not "chainless" either. To my mind, it matches the conditions for both "block" (ledger) and "chain" (linked hashes) . – Synesso Jul 28 '18 at 5:12
8

Unlike many blockchains, such as Bitcoin with its UTXO model, in Stellar every ledger includes a logical snapshot of the complete system state. This makes it possible to trim history while still having a working node.

That said, the consensus value actually contains a hash of the previous consensus value, as well as a skiplist to make it faster to search backwards. You can see these data structures in Stellar-ledger.x:

/* The LedgerHeader is the highest level structure representing the
 * state of a ledger, cryptographically linked to previous ledgers.
*/
struct LedgerHeader
{
    uint32 ledgerVersion;    // the protocol version of the ledger
    Hash previousLedgerHash; // hash of the previous ledger header
    StellarValue scpValue;   // what consensus agreed to
    Hash txSetResultHash;    // the TransactionResultSet that led to this ledger
    Hash bucketListHash;     // hash of the ledger state

    uint32 ledgerSeq; // sequence number of this ledger

    int64 totalCoins; // total number of stroops in existence.
                      // 10,000,000 stroops in 1 XLM

    int64 feePool;       // fees burned since last inflation run
    uint32 inflationSeq; // inflation sequence number

    uint64 idPool; // last used global ID, used for generating objects

    uint32 baseFee;     // base fee per operation in stroops
    uint32 baseReserve; // account base reserve in stroops

    uint32 maxTxSetSize; // maximum size a transaction set can be

    Hash skipList[4]; // hashes of ledgers in the past. allows you to jump back
                      // in time without walking the chain back ledger by ledger
                      // each slot contains the oldest ledger that is mod of
                      // either 50  5000  50000 or 500000 depending on index
                      // skipList[0] mod(50), skipList[1] mod(5000), etc

    // reserved for future use
    union switch (int v)
    {
    case 0:
        void;
    }
    ext;
};

The previousLedgerHash ensures history, and means that two validators that agree on the current ledger state also agree on the entire history. The bucketListHash is a logical snapshot of the current ledger state. (It's organized in a slightly special way to optimize rehashing, but is a collision-resistant hash of all ledger entries).

  • But if all "ledgers" contain a hash of the previous ledger, and those form a sort of linked list, doesn't that mean it actually IS a blockchain, i.e. that there's no practical difference between the concept of "blocks" as the term is used in Bitcoin and Ethereum and the concept of "ledgers"? – Ivan Voras Nov 19 '18 at 21:57
  • 1
    @IvanVoras That's correct. Stellar's block format is more like Ethereum than Bitcoin, but ut both are blockchains and Stellar is, too. – user3188445 Nov 21 '18 at 5:47
  • you write: "in Stellar every ledger includes a logical snapshot of the complete system state". I'm not sure I understand what you mean by ledger in this context. Are you referring to the object that's created every ~4 seconds? that certainly does not include all the state but only the latest changes to the state. Are you referring to the sum total of all those objects? that's the entire blockchain. – FuzzyAmi Feb 27 at 15:32
  • @FuzzyAmi I am referring to the LedgerHeader structure above, which is created every 5 seconds. The bucketListHash contains the complete ledger state, such that you do not need any past ledger headers to verify the complete state of the current ledger. This is different from Bitcoin, where the UTXO set is not checkpointed every block, but rather must be re-derived from the complete history. – user3188445 Mar 1 at 0:28
2

You say:

Since the computation of current hash does not depend on previous hash(...)

But if you read the documentation of Stellar, it says that the ledger depends on previous ledger:

This header has references to the actual data within the ledger as well as a reference to the previous ledger

https://www.stellar.org/developers/guides/concepts/ledger.html

0

Regarding your 2nd question:

To find an account details Do I need to traverse the stellar ledgers (like a link list) to find the last transaction details of an account or Do I directly query the account database and if its the latter case what is the guarantee that the database stored is the correct one ?

so in a sense the answer is "both". If you have a running Stellar-core with full catchup, after a while it would sync up with the rest of cores in the same "network" (group of cores working together, like stellar's testnet) - a process in which the core basically fast-replays the entire history of the blockchain into its own DB. Having synced, this core would have in its DB the current balance for every account. This syncing process can take days or even weeks depending on the amount of history of the network, but once done you can query the DB and get the results immediately. Note that the transactions themselves are not permanently stored on the DB, and are eventually kept in "history archives" - files on some publicly available drive.

Edit: the answer above assumes your core did a complete catchup: basically replayed the entire history from the very beginning. This is true, but there's another option: limited catchup. In this case, the core would slurp up the "state" of the blockchain from another core. This state does not include the entire history of transactions but does include the current state of every account. Your core would still be able to provide you with the state of accounts, just not with how they got there. Partial catchup means you're somewhat relying (ie trusting) on other nodes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.