4.3.4 DEC Account Design
4.3.4.1 DEC Addresses and Namespace Design
In the vast digital landscape of blockchain networks, a user's unique identifier is often referred to as an 'address'. This address acts like a mailbox, holding assets that belong to a particular user and allowing transactions to be executed accurately. Just like your physical home address, the digital address helps ensure that your assets (like DEC tokens) are sent to the right destination within the blockchain network.
One can draw parallels between these digital addresses and banking systems. For instance, the international banking system uses a standardized format called IBAN (ISO 13616) to identify account holders. Similarly, the SWIFT and BIC codes are utilized to facilitate international money transfers. This principle of unique identification is also utilized in blockchain networks like DGT and DEC.
In the context of the DEC protocol, these addresses have a more nuanced role. Unlike other networks such as Ethereum that primarily focus on transferring ETH, DGT leverages what we call 'transaction families' for its fundamental operations. These families have their unique namespaces, akin to areas of responsibility within the network, with each one being tied to a specific entry in the Merkle-Radix tree. This tree acts like a ledger that records the history and details of every transaction within the network.
Without diving too deep into technicalities, let's understand what these addresses look like in DEC protocol. These addresses are 70-character hexadecimal strings representing 35 bytes of data. They begin with a namespace prefix (6 characters long), which is like a specific area code allowing for over 16 million possible different areas (transaction families). The rest of the characters are specific to the transaction family and can be used to further categorize and identify unique transactions.
When DEC tokens are transferred, it's like making an entry in a ledger, with details about which funds went from which account to which other account. This ledger entry, or transaction, is confirmed with a digital signature, serving as a proof of the transaction. In DEC, the address design is similar to Ethereum's (EIP-55), a well-tested and widely accepted standard. The benefits of this compatibility are twofold. First, the Ethereum address has proven to be unique and reliable. Second, any user who has an address on the Ethereum network can also use the same address in the DGT/DEC network.
To generate an address in DEC any user or software should make:
- A public key is calculated using the user's private key (via a process called ECDSA- Elliptic Curve Digital Signature Algorithm).
- The 'mantissa' of the address, which is a technical term for the main body of the address, is calculated using a process known as Keccak-256 applied to the public key.
- The address is then trimmed to 20 bytes and prefixed with '0x', resulting in the final address.
The whole algorithm for obtaining a DEC address from a private key, the following steps are followed:
# | Step | Description |
1 | Key Generation | Generate a private and public key pair using an asymmetric cryptographic algorithm like ECDSA. |
2 | Public Key Derivation | Derive the public key from the private key. This process is deterministic and computationally straightforward. |
3 | Address Calculation | Compute the address using the derived public key. This step involves truncating the key to 20 bytes and adding the "0x" prefix as per Ethereum's EIP-55 standard. |
4 | Address Verification | Verify the address. The address should be deterministic (i.e., the same inputs consistently produce the same address), unique, and Ethereum-compatible. |
5 | DEC Address | Once the address is verified, it can be used as a DEC address in the DGT platform. |
4.3.4.2 Type of DEC Accounts
Accounts within the DGT network function as identifiers in transactions between users. Each account necessarily possesses an address. Even if an account only contains a single address (which can be generated offline based on specific rules), it can receive funds within the limits set at the network's initiation. The accounts in the DGT system can be categorized as follows:
System Accounts: These are unique accounts like _DEC_EMISSION_KEY and CORPORATE_ACCOUNT defined at the time of issuance. They serve as special synonyms for complex operations that are based on the direct reading of the registry. Operations involving these accounts require multi-signature authorization, which can vary depending on the operation - for example, a threshold of 3 out of 4 or 2 out of 4 signatories.
Plain Accounts: These are simple accounts created directly via a cryptographic address. Each account corresponds to an existing public key, making it an address derived from the public key or the public key itself. Operations with these accounts are regulated by the protocol.
Complex Accounts: These are essentially sets of individual accounts (addresses) tied to one DID (Decentralized Identifier) and several additional attributes that determine the account's operational policy.
Aliases: These represents the account address symbolically (for example, via email or a phone number), serving as a special synonym.
Empty Accounts: These accounts have received funds but do not yet have an owner. For instance, money can be transferred to a non-existent address (or alias) where the owner is not yet registered. These operations can equate to burning unless a pre-generated private and public key exists for the received address. Though the account might contain funds, it will be inaccessible without the necessary keys.
Shielded Addresses: These are featured in certain blockchain and cryptocurrency systems to enhance transaction privacy. They conceal the transaction details, hiding the identities of the sender and receiver as well as the transacted amount. Shielded addresses employ a type of cryptography known as zero-knowledge proofs, specifically a variant called Bulletproof or zk-SNARKS (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge). These proofs verify the truth of a statement without revealing any information beyond its truth.
4.3.4.3 Plain Accounts
Plain Accounts in the DGT network are the simplest form of accounts. They are created directly via a cryptographic address and correspond to an existing public key. In essence, a plain account is an address derived from the public key or the public key itself.
A Plain Account has these key characteristics:
It's linked to a single address, which is essentially the public key or derived from the public key.
It has a limited set of functionalities, constrained by the network protocol.
It can receive and send funds within the limits set by the network.
It's feasible to be created offline based on certain rules.
Public Key: | 04a1df2d3cdf4948b79a88c1526915b327651e4e3ae1bb30706713c8ebcd4c12 |
Address: | 3P3V5KY6VWtLZ5zQskB3ZM9AzGN5n98yCP8 |
Account Balance: | 100 DGT Tokens |
Operations allowed in a Plain Account might include, but are not limited to:
Receiving funds: The Plain Account can receive tokens from other accounts within the network.
Sending funds: The account can send tokens to other accounts within the limits set by the network.
Checking balance: The account balance can be checked at any time.
Please note that all operations in a Plain Account are bound by the rules defined in the DGT network protocol, and the account can be upgraded to a Complex Account if the need arises. This could be done for additional functionalities such as executing complex operations, setting operational policies, or associating with multiple addresses and DIDs.
4.3.4.4 Complex Accounts
In the DGT platform, the typical distinction between accounts and wallets is somewhat blurred. Here, an account can represent both a simple address and a complex entity (a wallet) that consolidates multiple addresses, each with additional attributes.
Tokens can be transferred either to a direct address, which is produced by transforming the public key as described earlier, or to a bundled set of addresses, each with additional attributes. These attributes define the parameters of valid transactions and play an essential role in Know Your Customer (KYC) and Anti-Money Laundering (AML) procedures. Users with simple accounts, comprising a single address without attributes, can execute a limited number of transactions and transfer limited amounts. Transactions on these addresses are restricted in the same way as regular UTXO accounts on the blockchain.
Complex accounts, or wallets, comprise a set of addresses (at least one) and a collection of attributes (could be extended):
ATTRIBUTE 0: DID, a unique identifier derived by hashing the address (SHA256). This identifier follows the W3C DID standard.
ATTRIBUTE 1: DELAY, the minimum time allowed between transactions involving these addresses.
ATTRIBUTE 2: LIMIT, the maximum amount that can be withdrawn at once.
Creating such complex accounts (wallets) requires the involvement of notary nodes. These nodes assign unique identifiers (DIDs) and may assign additional attributes. These attributes enable the system to impose transaction restrictions based on various factors, such as citizenship.
Complex Account Protocol:
· Every invocation of the wallet command creates a unique address, which is always associated with a unique Decentralized Identifier (DID).
· If users wish to link an existing DID to a new address (or generate a new DID if none exists), the services of a notary must be employed.
· For segment wallets, ATTRIBUTE 1 and ATTRIBUTE 2 must be inherently defined. These attributes, set through the account command, allow for regional customization and specific tailoring of business operations.
· The creation of complex accounts should adhere to time constraints. To prevent oversaturation, each wallet should not be created more than once within a predetermined period.
· The wallet command serves dual functions: it appends specific attributes to an address and generates a transaction list for the corresponding complex account (wallet). The system facilitates the transfer of tokens to any address, provided it passes a checksum verification.
· A unique attribute of these complex accounts (wallets) is their ability to conglomerate multiple addresses, identifiers, digital objects, and sub-tokens. This results in a unified, manageable account.
· Furthermore, each address can also be represented by an alias or symbolic link, making them more user-friendly and easier to recall. This enhances the user experience by simplifying account management and token transfer processes.
This approach enhances the flexibility of the DGT network, while ensuring user security and compliance with relevant regulations.
4.3.4.5 Aliases
Crypto addresses, while securely generated and practical for pinpoint addressing, can often be inconvenient for practical usage due to their large size or the potential compromise of the keys from which they are derived. To address this issue, the DGT system introduces address synonyms, or aliases. These aliases are unique symbolic names that can be associated with any address, like how the Domain Name System (DNS) maps domain names to IP addresses. Here are some key points to remember about aliases:
· A single address can be associated with multiple aliases.
· Aliases can be marked as invalid using a specific procedure.
· Aliases are easier to recall and utilize. They can be represented by real-world identifiers that are already in use, such as an individual's email address or phone number.
Just like with any real-world identifier, ownership of the alias needs to be proven to avoid misuse. In the DGT system, this validation process is conducted by notary nodes, which act as intermediaries between the network and the real world. Issuing an alias requires the involvement of specialized services for verification, like checking email or sending SMS to the specified phone number. Upon verification, the notary records a unique hashed code through a special transaction and provides the user with the same code in plain text through off-chain channels. The user can then, in a separate transaction, confirm the existence of this code and link the corresponding alias to their address. This two-step process secures the association between the alias and the address, ensuring that the user is indeed the owner of the address.
The alias service could be enhanced with the following features:
Alias Transferability: Secure mechanisms for alias transfers from one address to another.
Expiration Dates for Aliases: Aliases could have expiration dates, necessitating renewal and freeing up unused aliases.
Alias Privacy Settings: User-controlled settings to determine public visibility of alias-address associations.
Multi-Factor Authentication (MFA): Enhanced security for alias-related actions, like creation, transfer, or address association, via MFA.
Revocation Mechanism: In case of alias compromise, or if the associated identifier is no longer valid, the user should be able to revoke or dissociate the alias.
Alias Directory: A searchable directory of public aliases, respecting privacy settings, could be established for easy verification and lookup.
Confirming ownership involves notary nodes recording a hashed verification code with a special transaction while also providing the user with the same code via off-chain channels. The user can then confirm the code, thereby linking their alias to their address securely.
4.3.4.6 Shielded Addresses
The widespread use of cryptocurrencies has led to a major concern: privacy. Blockchains, while providing a secure and transparent platform for financial transactions, may compromise privacy due to their inherent transparency. Every transaction made on a public blockchain can be seen by all network participants, allowing anyone to trace the transaction history of a specific blockchain address and potentially deduce information about its owner. In simple terms, a blockchain is a digital ledger of transactions that is duplicated and distributed across an entire network of computer systems. The transactions, in this case, relate to cryptocurrencies.
Furthermore, certain methodologies can associate blockchain addresses with real-world identities, leading to exposure of sensitive financial data. This absence of privacy can lead to several issues including personal security threats and a compromise of commercial confidentiality. For instance, if a person's financial wealth can be deduced from their blockchain transactions, it might make them a target for scams or theft. For businesses, confidential transaction data might be used by competitors to infer business strategies. This is where shielded addresses and private transactions become crucial. They provide a method for transacting on the blockchain while preserving the privacy of the involved parties.
DGT supports private transactions at the protocol level and external services. A detailed description of the implementation of private transactions is given in the book "DGT ARCHITECTURE", here explanations are given with an emphasis on the created hidden addresses (shielded addresses). The scheme for organizing transactions with hidden addresses is based on the following basic steps:
Transaction Initiation: A user starts a transaction using their standard blockchain address. This is an on-chain action and can be viewed by all network participants.
Address Generation: A mixer, which is an external service, generates two unique addresses. This action is off-chain, and therefore, hidden from the network.
Fund Transfer: The funds are transferred from the sender's initial address to one of the newly created addresses. Simultaneously, an equivalent amount is transferred from the second new address back to the receiver's initial address. These transfers are done on-chain but are designed to be untraceable due to the use of new, unrelated addresses.
Mixer Destruction: The mixer service discards all data about the new addresses after the transaction is complete. This ensures no linkage can be made between the original and the new addresses, enhancing transaction privacy.
The structure for managing shielded addresses could involve the following:
Privacy-Preserving Cryptography: Techniques like Zero-Knowledge Proofs (ZKPs) or zkSNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) could be used to verify transactions without revealing any other details.
Mixer Services: These are vital components that generate temporary, untraceable addresses for each transaction. A mixer service is implemented as a component of Notary service.
Wallet Integration: Wallets that support transactions using shielded addresses would interact with the mixer service to initiate and complete private transactions.
Protocol Level Support: The DGT protocol itself supports the use of temporary addresses and the capability to transfer funds to and from these addresses.
However, as with any technological advancement, there are potential challenges or drawbacks. While privacy is advantageous, it could also be misused for illicit activities. Therefore, a balanced equation for shielded addresses and private transactions would consider the need for privacy along with transaction validation and security, ensuring that while transaction details are obscured, the transaction itself is valid and does not result in double-spending of funds.
At the Figure below we present an improved system for conducting private transactions within a blockchain network using shielded addresses. The system effectively masks the transaction's sender and receiver details while maintaining the core attributes of trust, security, and verifiability of blockchain technology. The process involves two primary users, Alice, and Bob, interacting with their respective wallets, a Mixer Service, a Notary Ring, and the overarching DGT Network. The Mixer Service, a key player in this scheme, creates new temporary shielded addresses for transactions and provides a proof of action, stored securely by the Notary Ring in a Verifiable Credential (VC) Storage. This ensures transaction legitimacy and helps to maintain a reliable audit trail.
The transfer of funds happens from Alice to Bob through these newly generated, untraceable addresses, which eventually get destroyed to preserve the users' privacy. The DGT Network, incorporating the Notary Ring, serves as the validating and processing entity, confirming transaction completion and the eventual destruction of temporary addresses.
In shielded transactions, new temporary (or "shielded") addresses are generated for each transaction. Alice's funds would be transferred to a new shielded address generated specifically for this transaction. From the perspective of an outsider looking at the blockchain, it would appear as if Alice has transferred her funds to some unknown address.
Similarly, when Bob receives the funds, they would be sent to a new shielded address that was also generated specifically for this transaction. From Bob's perspective, it would look like he received funds from some unknown address. The real identities behind these addresses are known only to Alice, Bob, and the mixer service. The key here is that the new addresses are not explicitly linked to Alice and Bob's original addresses on the blockchain. This is achieved using various privacy-enhancing techniques such as zero-knowledge proofs (ZKPs) or other cryptographic techniques. As for the mixer service, it does not need to hold the funds themselves. Its role is to facilitate the creation of the new shielded addresses and orchestrate the transactions between them. It's important to note that the actual funds always stay within the control of Alice and Bob, which is crucial for trust and security.
Last updated
