INACTIVE. Server in the Stellar network. Maintains the distributed ledger. Introduces and validates transactions. This repo is not in active development, it is being replaced by stellar-core.
Other
270
stars
60
forks
source link
save history as just txns and an occasional full ledger checkpoint #79
Ledgers (both state and history) are currently stored as fine-grained SHAMaps, one for transactions and one for the state of all accounts and other ledger-objects (orders etc.).
We would like to move away from using SHAMaps for both aspects of storing a ledger. This bug is about the ledger-header and transaction SHAMap. For the account-state representation, see bug #118
As a history-storage device for a set of transactions, SHAMaps seem non-optimal: the hash order they store transactions in is not the order transactions were applied to the ledger in, the interior nodes are not useful in sharing subsets of transactions between ledgers, and there are seldom enough transactions in a single ledger to benefit significantly from the Merkle structure (as in bitcoin SPV)
We would like to store ledgers as simple linear blocks, each beginning with a ledger-header (with parent hash, timestamp, various auxiliary fields and hashes for account-state and transaction-set) followed by the transaction-set of that ledger, as a linear array of transactions, in the order they are applied in that ledger.
Indexing transactions by hash or other value (account affected, previous ledger, etc.) can be done secondarily by other storage representations in other processes (eg. expanded-out SQL tables with secondary indices).
Ledgers (both state and history) are currently stored as fine-grained SHAMaps, one for transactions and one for the state of all accounts and other ledger-objects (orders etc.).
We would like to move away from using SHAMaps for both aspects of storing a ledger. This bug is about the ledger-header and transaction SHAMap. For the account-state representation, see bug #118
As a history-storage device for a set of transactions, SHAMaps seem non-optimal: the hash order they store transactions in is not the order transactions were applied to the ledger in, the interior nodes are not useful in sharing subsets of transactions between ledgers, and there are seldom enough transactions in a single ledger to benefit significantly from the Merkle structure (as in bitcoin SPV)
We would like to store ledgers as simple linear blocks, each beginning with a ledger-header (with parent hash, timestamp, various auxiliary fields and hashes for account-state and transaction-set) followed by the transaction-set of that ledger, as a linear array of transactions, in the order they are applied in that ledger.
Indexing transactions by hash or other value (account affected, previous ledger, etc.) can be done secondarily by other storage representations in other processes (eg. expanded-out SQL tables with secondary indices).