Stellar is one of the platforms that use blockchain to make money transactions more fast and secure. Where you can build mobile wallets, banking tools, smart devices that pay for themselves, and just about anything else you can dream up involving payments! Why stellar is unique than other chains are because it builds on top of a hybrid architecture that contain SQL DB + Blockchain. And the main advantages in stellar is the transaction fee is very low (equal to 0.00001 XLM) compare to other chains. A person can make around 390,000 transactions for 1$. And the throughput also high compare to other chains.
Lumen, or XLM, is the digital currency unit of Stellar.
NOTE: — In stellar there is no mining fee (gas). That means there is no work for miners and you can’t earn coins by mining. Stellar does not have a mining-based currency. At the network’s genesis, 100 billion stellars were created. The only other stellar creation mechanism is inflation. To account for both economic growth and lost stellars, there is a fixed 1% annual rate of new stellar creation. These new stellars will be generated on a weekly basis and distributed via a direct voting method.
stellar consist with main two components. one is stellar core and other one is stellar horizon. All the nodes in the stellar network need to have both these components to communicate with network. And validation nodes need only stellar core. Stellar network is a collocation of stellar cores and each maintained by different people or organization. The security and reliable maintained by the decentralized nature of the network.
All the transactions in stellar will be happen through horizon, a RESTful HTTP API server. It allows users to submit transactions, check accounts, and subscribe to events. Simply anyone can communicate using their web browser because it’s just HTTP. Even make the communication and development easier stellar contain various of SDK’s in all famous programming languages and as mentioned stellar is opensource.
Stellar core is the backbone of stellar network. Each horizon server will connect to stellar core. Stellar core is the part that doing the massive amount of work and process to validating and agreeing with other stellar cores to accept the status of each transactions. The whole validation process will happen through Stellar Consensus Protocol (SCP). Stellar not using the proof of work or proof of stake mechanism to validate transactions, it’s using federated Byzantine agreement (FBA).
For more details explanation about Stellar Consensus Protocol white paper.
If we look into stellar core it contains current ledger, SQL DB and the details about history data. The current ledger will contain current and more recent transactions and database will hold the current transactions as well as the modifications or effects that happen after the transactions. For example, if stellar core out of sync with it peers due to crashed or when joining the first time it will get the details from the history archive to maintain the same version of chain. We will discuss more about database, ledger and history archive in the below section.
So finally, stellar core is the most important component in the stellar network and it contain ledgers and DB to record the transactions and contains SCP to validate and approve the transaction.
How stellar store transaction (Behind the scenes)
This section will give more depth view of stellar transaction flow and each component that take part to store the transaction entry. Below are the main components that working to store the transaction entry.
Ledger: — A ledger represents the state of the Stellar universe at a given point in time. Ledger will contain all the current transactions details that happen recently. The first ledger in history is called the genesis ledger (We can relate a ledger to a block). Approximately a ledger will be closed each 5s. And then the ledger manager will open a new ledger immediately. Each closed ledger will contain closed timestamp. Each ledger will have hash value of the stored transactions and unique sequence number. Each ledger will link to the previous ledger by referencing the hash.
Ledger Header: — Each ledger will have ledger header that contains transaction set #, bucket list # and the previous ledger #, closed time and Transaction Set Result #.
Below image will give a clear view about ledger and what are the important information's stored in ledger header. (Tx -> Transaction)
Database (DB): — As mentioned before stellar having a hybrid storage architecture where data will be stored in DB as well as in ledger. Stellar core has a SQL DB that consist all the necessary tables that need to run stellar network. Each transaction data, history of transaction, transaction fee and all the modifications will be added to the database.
For an example of there is a account creation happen it will record to the account table.
Bucket & Bucket list: -The large set of ledger entries redundantly storing in a secondary structure called bucket list to efficiently calculating a cryptographic hash of the entire set, after each change to it. And efficiently transmitting a minimal “delta” of changes to the set, when a peer is out of sync with the current ledger state and needs to “catch up”.
Bucket list contain fixed number of levels and each level contain 2 buckets. The size of the bucket will be double the size of the previous level bucket. the transaction records will be store in the bucket and the cumulative # of the bucket levels will create the bucket list #.
Each level is split to 2 halves, one is curr and other one is snap. The more recent ledgers will store in the curr and the older ones will be taken as a snapshot and stored in the snap bucket. Once the size of curr increased more than 1/2 of snap then the snapshot of the curr will be stored in the snap and curr will be cleared and once the snap increased it will moved to the next level snap.
More detail about the bucket list structure can found hear.
History Archive: — The history will be created by the action of ledger manager. Once the ledger closed the history table in SQL will be updated. Also, once the bucket list contains more old ledgers then it will take the whole thing as a one snapshot and store it in history archive. The history module is responsible for interfacing with “history archives”, loosely defined as “places that flat files can be stored and retrieved from”. Records are generally XDR files (RFC 4506) compressed with gzip (RFC 1952).
As shown in the above image once the transaction gets validated straight away it will inserted in to the open ledger. If the transaction comes while the ledger in closing process it will be stored in queue and will be insert in the next open ledger. once the ledger starts the process to close, all the transaction will be sort based on the sequence order and will start process to calculate each transaction #. In the end each calculated transaction # will be combined to calculate the final transaction set #.
Once it’s done all the transaction process will be stored in DB and the ledger delta will created by the modifications or changes happen to the tables due to the last ledger. Then the ledger will be closed, and the transaction hashes will be send to bucket list.
Once its arrived at bucket list it will stored in the different levels of bucket based on the age of the transaction. More recent modification entries will store in the low-level buckets and the old ones will be stored in the higher-level buckets. And the total bucket list # will be calculated and stored in the ledger header as a bucket list #.
Smart Contract in Stellar
Stellar not having a Turing machine similar like Ethereum. So, it cannot compute whatever we insert. But still can do smart contracts that are controlled by the transaction sequence number and trusted parties. two people can write a contract to transfer something based on some set of conditions and execute it between them by using sign authorizations. And even more advance stellar introduce time bound transactions where once we created the contract and until the specified date no one can execute that transaction.
But the main disadvantage with stellar contracts are its not stored in the chain itself similar like Ethereum. It stores only the define transactions and the if then else rules will be stored outside. Due to the feature of transaction sequence number its looks secure. Other than money transaction, IOC and assets transfer contracts stellar is not much efficient and flexible to create a contract between two non-trusted people. And it’s not storing the code and executing inside the blockchain so not suitable for Dapp’s as well.
As a conclusion stellar fulfilling the reason why its created by providing high throughput for less transaction fee. Stellar is more focused on micro payment and ICO’s and that’s why they not focusing to integrate Turing machines because it will affect their throughput.
Whoever want to start ICO or micro payment systems using blockchain should check stellar. And it will never disappoint you. Stellar started the process slowly and silently and it got big reach to blockchain/crypto community after IBM started using stellar to connect banks to make currency transfer.
Note:- This section not discussing about how Stellar Consensus Protocol works in order to validate the transaction. Hope to share a separate post about that.
Looking forward your feedback’s and comments :). If there are any corrections need to be done please mentioned those in comments. To Write this post I researched and gathered information from stellar.org, github stellar core repo and stellar slack. The reason I wrote this is to support the stellar community and who ever likes to learn the back-end process of stellar. I hope this post will help people to easily understand the behind the scenes in stellar rather than going thorough whole github stellar core repo which is more technical.