Core is a replicated state machine that maintains a local copy of a cryptographic ledger and processes transactions against it, in consensus with a set of peers (forked from stellar-core). It implements the Stellar Consensus Protocol, a federated consensus protocol. It is written in C++14 and runs on Linux, OSX and Windows. Learn more by reading the overview document.
All notable changes to this project will be documented in this file. This project adheres to Semantic Versioning.
Documentation of the code's layout and abstractions, as well as for the
functionality available, can be found in
./docs.
To update xdr-generated files:
./generateXDR.sh mastergit submodule update --init
cmake CMakeLists.txt -DPostgreSQL_INCLUDE_DIRS=/usr/include/postgresql/ -DPostgreSQL_LIBRARIES=/usr/lib/libpq.so -DOPENSSL_ROOT_DIR=/usr/lib/openssl-1.0 -DOPENSSL_LIBRARIES=/usr/lib/openssl-1.0 -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0
make -j8Expect warning:
warning: libcrypto.so.1.1, needed by /usr/lib/libpq.so, may conflict with libcrypto.so.1.0.0
Make sure You typed correct paths to the libs. Consider replacing -j8 according to the number outputed by:
# nprocgit submodule update --init
cmake CMakeLists.txt -DPostgreSQL_INCLUDE_DIRS=/usr/include/postgresql/ -DPostgreSQL_LIBRARIES=/usr/lib/libpq.so
make -j8The core of TokenD is based on the open-source project stellar-core. TokenD uses SCP as consensus protocol, concept of ledger and have the data flow process as stellar-core. However there are several important improvements.
Basically, accounts in stellar-core all have equal possibilities for performing any kind of operation. TokenD's core introduces account types (e.g. master account, general account etc). Any operation falls restrictions about account types which could perform it. As an example, this change makes it possible to create very easily certain system operations which should not be performed by ordinary accounts. TokenD going farther and introduces signer types. Both together this feature contributes to flexibility of how operations are performed.
One of the most noticeable change is the process of issuance of new assets.
In order to issue some amount of a new asset in stellar-core, the receiver must
hold a trust line in corresponding asset. The amount can be transferred to receiver via
payment operation.
TokenD uses more sophisticated approach and divides this process into
processing of pre-issuance and issuance requests. Durring asset creation (which is two step process for syndicates),
syndicate is able to provide information like max issuance amount and pre-issuance signer, which restrict total amount of that asset available in the system.
After asset request is approved, syndicate is able to send pre-issuance request (which includes signature of pre-issuance signer).
As soon as this request is approve by the admin of the system (signer of master account), syndicate is able to send issuance request which must include unique reference of such request
(if pre-issued amount is not sufficient, pending issuance request will be created
which can be approved by the syndicate, when sufficient pre-issued amount is available or reject it).
Such an approach is much more safe and reliable and makes integrations with TokenD much easier.
Stellar-core have only a constant fee per transaction. In TokenD it was implemented a reach system of fee charging which gives and opportunity to set different fees for different operations (by introducing fee type), set fees for each account type or even for certain account. Also it is possible to charge a percent fee from an amount.
TokenD contains a big list of operations comparing to stellar-core which is enough to fulfill needs encountered by tokens management systems.