DRM Overview
DRM's ledger is a distributed database for storing financial transactions. In many ways, it's similar to traditional databases you might be familiar with, such as the SQL PostgreSQL or NoSQL MongoDB, but there are some key differences:
- The ledger specializes in storing financial data and small amounts of metadata.
- The ledger is permissioned, so a cryptographic key must digitally sign every operation.
- Keys are granted access through a Role-Based Access Control (RBAC) system.
- Since the ledger has been optimized for financial transactions, it is also very high-performance, capable of achieving up to one million transactions per second with less than a second latency (time to finality).
BFT
Unlike many traditional distributed databases, the DRM ledger is byzantine fault tolerant (BFT), which is used in blockchains such as Bitcoin. In summary, BFT is a distributed system that can withstand failure or malicious intrusion by some nodes before being compromised. DRM's ledger is based on proprietary blockchain technology that optimizes financial transactions by regulated financial institutions. The DRM ledger is private, which means that a single entity, or a small group of trusted entities, runs the ledger. This allows us to achieve higher performance and much lower computational and environmental costs than public blockchain-based systems.
Hierachical ledger
The DRM ledger is hierarchical, which means that its accounts form a tree, as shown above. In the example, we assume the central bank operates the USD root account and issues M0 money to Tungsten Bank and Iron Bank.
M0 and M1 are two of the most common measures of the money supply in an economy. They differ in their liquidity, or how easily their components can be converted into cash.
M0 money: This is the most liquid measure of the money supply. It includes:
- Physical currency in circulation: This means all the notes and coins that are held by the public, businesses, and financial institutions (excluding the central bank).
- Bank reserves: These are the deposits that commercial banks hold at the central bank.
- M0 is often referred to as the "monetary base" because it is the foundation upon which other forms of money are created.
M1 money: This measure of the money supply includes everything in M0, plus:
- Demand deposits: These are checking accounts that can be accessed easily using checks, debit cards, or electronic transfers.
- Traveler's checks: These are prepaid checks that can be used as cash when traveling.
- Other checkable deposits: These are similar to demand deposits but may have some restrictions.
M1 is considered a narrower measure of the money supply than M2, which includes additional less-liquid assets like savings deposits and money market funds.
On the DRM platform, we use the terms M0 and M1 to represent money issued by a central bank (M0) and depository institutions (M1).
Tungsten Bank and Iron Bank then issue M1 money to their customers. An account is similar to one you might have at a bank. It has a balance, a name, and, in our system, a parent account. This gives the ledger the ability to model fractional reserve banking and provides a clean permissions model. When a transfer occurs between two accounts, it traverses the tree to find the path between them. You'll find more details about this in the API docs under accounts and transfers.
RBAC
RBAC is a standard model for permissions in enterprise software. The idea is that roles contain a list of permissions for a particular resource. Each role is "bound" to a user with a role-binding. DRM uses an RBAC system for all permissions in the ledger. More details can be found in the role and role-binding docs.
Documents
The ledger can store documents in addition to financial transactions. Documents are stored in collections, groups of documents with the same protobuf type. Documents are typically used to store metadata on the ledger. An example is the Bank
document. Bank
contains metadata about a bank that exists on the ledger. APIs are used to query Documents.
Actions
The ledger also supports sending messages between accounts using an interface called actions. It allows someone with permission to an account to subscribe to a stream of actions taking place on the account. This is similar to a message queue system like Kafka. For example, an account could receive an FX ask or bid from a market maker. The party subscribing to actions on the account would instantly receive the ask or bid information.
APIs and SDKs
Authorized parties can interact with the ledger through a publicly available API. The DRM API is gRPC-based and uses protocol buffers (Protobuf) for serializing data. The advantages of using Protobuf over XML or JSON are high performance, backward compatibility, built-in versioning, and high data-integrity from strong typing.
While Protobuf's binary format is efficient, text-based formats like JSON are more human-readable. This can make debugging Protobuf more complex, so we will provide advice on troubleshooting throughout this guide.
gRPC leverages HTTP/2 to enhance performance since it's a modern transport protocol that offers features like multiplexing, header compression, and server push. However, some IT environments don't support HTTP/2 and require HTTP/1. To accommodate HTTP/1, the DRM SDKs include an http client.
SDK languages
To further ease application development, the DRM platform offers SDKs in the following languages:
To learn more, see API Docs.