Difference between Stellar Ledger and Blocks

Question

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 ?

Answer 1

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).

Answer 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

Answer 3

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.