Technical White Paper

Transcription

1 Technical White Paper IXIAN WHITE PAPER 1 hello@ixian.io

2 IXIAN Technical White Paper V 0.4 The Technical White Paper is a live document and is subject to change. You can always find the latest version on Nov 2017 Authors (in no particular order): Marko Arh-Tadič, project lead Damir Rekić, UX lead Marko Žagar, software architect Cristian Ciorba, lead developer Mina Kržišnik, legal & PR lead IXIAN WHITE PAPER

3 Contents Contents... 1 Glossary... 3 Quick About Project IXIAN... 4 IXIAN Distributed Ledger Technology... 5 Use of IXIAN DLT for developers... 5 Use of IXIAN DLT for general public... 6 IXIAN Secure Streaming Network... 6 Use of IXIAN S2 for general public... 6 SPIXI Blockchain based Instant Messenger... 7 Main features of SPIXI:... 7 Use of SPIXI for general public... 7 IXIAN Technology Technical Details... 8 IXIAN DLT... 8 Blockchain and history... 9 Included transactions Invalid transactions Wallet state in blockchain Transaction pool and accepting the new block Normal operation - graphical representation Begin new block calculation - graphical representation Incoming block has fewer transactions graphical representation Incoming block contains more transactions graphical representation Incoming block is accepted by the network graphical representation Blockchain rewards Calculating the flat amount Awarding DLT API Algorithms IXIAN S2 Secure Streaming Network IXIAN WHITE PAPER 1

4 Presence List Presence List Authority PL Replication between Master nodes Communication Scale-out streaming Stream payments: Lack of trust Conclusion References IXIAN WHITE PAPER 2

5 Glossary Node Device connected to a network of other devices operating on the same protocol. Distributed Ledger Technology (DLT) DLT is a technology that allows data replication, sharing and synchronization across multiple nodes. There is no central administrator, no centralized data storage and no single point of failure. Blockchain Blockchain is a DLT that is used to maintain a continuously growing list of records, called blocks. Each block contains a timestamp and a link to a previous block Cryptocurrency/Cryptoasset A digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units of the currency. Since it operates in a trustless system it has no central authority and no single point of failure. IXIAN Redacted blockchain (IXIAN DLT) A Blockchain-like DLT that does not require full history of transactions/blocks for normal operation. IXIAN Instant Messenger (SPIXI) Fully decentralized and secure instant messenger application, powered by IXIAN DLT and IXIAN Network. IXIAN Streaming Network (IXIAN S2) A network consisting of IXIAN Nodes and IXIAN Redacted DLT Nodes IXIAN Coin (IXI COIN) Currency used for paying for services in IXIAN S2 and IXIAN DLT IXIAN Wallet (IXI PAY) An application, integrated in SPIXI, which is developed specifically to send and receive IXIs and other cryptocurrencies as well. IXIAN WHITE PAPER 3

6 Quick About Project IXIAN The whole story of IXIAN, one that eventually lead to revolutionary and innovative products, began on one hot Thursday afternoon. As an important discussion was taking place, the unthinkable happened. The messaging service we were using went offline, stopping our conversation immediately. Transferring to a different messaging service would have been a very frustrating and time consuming effort, on top of that we didn't have access to our discussions message archive. The communication was essential for the work we were doing. Given how such a relatively small nuisance caused a significant delay and compromised our work, we concluded that a fast, secure and reliable messaging service was needed, and that we should be the ones to develop it. The original idea was to develop a centralized instant messaging app tailored to our needs, however this solution turned out to be unfitting. A centralized app could never provide us with the reliability, privacy, speed and security we needed and wanted. The option to develop the application on one of the existing blockchain platforms seemed to be the way to go. After testing various existing implementations, we ve discovered a considerable amount of limitations, prompting us to develop our own DLT. Our ambitions though, were to be able to provide ourselves and others alike a unique yet familiar experience - an instant messaging app where all the messages would be transferred directly between the users in question, that sending messages through it would be secure and fast. More to that, what if users would be able to order/pay/receive various digital services or data? What if they could transfer money, provide/charge services, transfer all types of sensitive data through this app, whilst being guaranteed security? It all amounted to an overwhelming project, one that seemed a bit too ambitious at first. But one that we accepted nonetheless. IXIAN WHITE PAPER 4

7 IXIAN Distributed Ledger Technology IXIAN Technology encompasses the environment and tools that will change the way we think about blockchain technology. IXIAN Redacted Blockchain or IXIAN Distributed ledger technology (IXIAN DLT) represents an ambitious new concept that does not require full blockchain history in order to operate. This is a significant feature, allowing IXIAN DLT to be several magnitudes smaller than that of other blockchain technologies available today, such as Ethereum and Bitcoin. The main advantages of the IXIAN DLT: - Consensus-based block acceptance that allows the network to dynamically adjust the requirement for block validity. - Mathematically stable block validation. Acceptance of transactions and validation of new blocks is confirmed quickly and efficiently using a deterministic lockstep algorithm. - Limited blockchain growth - IXIAN DLT will eliminate the need for a very large blockchain. - No proof-of-work required. The IXIAN DLT can function even with a very limited processing power. - Entire wallet state is linked to the current block. This is a unique advantage that provides the ability to quickly see the current state of wallets even on low-powered devices with limited bandwidth. Use of IXIAN DLT for developers Developers will be able to create their own coin on top of IXIAN DLT, having a fixed conversion rate with IXI coin. Being one of the first blockchains that supports a fixed conversion rate, we have taken great care that developers can integrate IXI coin in their software, games, websites and more. IXIAN WHITE PAPER 5

8 Use of IXIAN DLT for general public Users will be able to transmit micro transactions. In practice this means that users will be able to pay or receive transactions of small amounts, without paying an enormous or disproportionate fees. An example of this is that a user can charge any fee (no matter how small or big) for streamed content. This way users may reduce their streaming costs, stream fast and securely and thus reach a wider net of potential clients. IXIAN Secure Streaming Network At the core of this project lies IXIAN streaming network, the sum of all connected software clients. Using our revolutionary DLT, the network can establish direct connections between users, on P2P principle and without any intermediaries. This allows its users a low-latency and secure communication. Through the use of incentive-based relay nodes, the network can maintain stability and optimize connections. Anyone that uses IXIAN S2 can operate as a relay node, allowing every user to gather valuable IXI Coins while making the network stronger. Now you can stream your photo, video or other content safe and fast. Use of IXIAN S2 for general public With IXIAN S2 users do not connect to a central server (as with other chat apps/services), instead they connect directly to each other. This way they are able to transfer messages, audios, videos and other data and money in a matter of seconds. Why is this an advantage? Users do not have to pay for third party services and do not have to worry about potential data leaks, privacy issues or even censorship. This is the core function of our IXIAN S2. Developers can use IXIAN S2 to build and monetize solutions that require secure streaming capabilities. Services utilizing IXIAN S2 require smaller operating budgets and can as a result be provided at a considerably lower cost compared to other alternatives. IXIAN WHITE PAPER 6

9 SPIXI Blockchain based Instant Messenger SPIXI is a truly decentralized, secure and private chat app that delivers an experience users are familiar with, but still offers the highest level of security, privacy, simplicity, data and money transfer, and more. Users have opportunity to ask for and charge for services and earn money with a simple use of the integrated multi-cryptocurrency wallet. SPIXI maintains all the basic features of the current chat apps, such as video calls, voice calls chats, image and file transfer, group chat, and more. Main features of SPIXI: - reliable, with no downtime, - custom distributed ledger technology for optimal decentralization, - cryptographically secure messaging that offer the highest form of privacy and security, - end-to-end data streaming, - multi-platform support, - ability to buy and sell premium services directly within the app. Use of SPIXI for general public Users will enjoy completely private text and video chat, file and data transfer, money transfer, content sharing and much more. All messages, data and transactions are securely encrypted by ECDSA, a proven cryptographic method. Users will even be able to charge for content and services (i.e. remote assistance, tarot reading, online tutoring, etc...). IXIAN WHITE PAPER 7

10 IXIAN Technology Technical Details IXIAN DLT This is a severely Redacted Blockchain, which is the core technology of the IXIAN network. It enables IXIAN to integrate new nodes quickly and efficiently, with lesser strain on the bandwidth than existing blockchain applications. The basic tenets of the Redacted Blockchain are: Severely reduced blockchain size: IXIAN blockchain aims to be several orders of magnitude smaller than other offerings on the market, allowing usage on devices with limited storage, such as Raspberry PI, embedded Atom, small, all-in-one servers. The full IXIAN client (the wallet application) can run on smartphones, giving users unprecedented, direct access to the blockchain without third-party intermediary services. Consensus-based block acceptance: Traditional blockchain validation determines validity by the length of history the longest chain of blocks is the canonically valid one. While that approach has been proven to work in practice, IXIAN DLT employs a consensus-based approach. This allows the network to dynamically adjust requirement for block validity. The initial requirement is set at 75%. Mathematically stable block validation: Acceptance of transactions and validation of the new block can be calculated and reached by the majority of nodes using an algorithmic approach known as deterministic lockstep. With a large part of the network automatically reaching the same result, validity of the current block is confirmed quickly and efficiently. Limited blockchain growth: One of the larger problems with traditional systems is growth of the blockchain. At the time of writing, Bitcoin chain weighs in at above 120GB, while Ethereum is already over 30GB. Plans to reduce the blockchain are forming, but as of yet no practical solution has appeared. IXIAN S DLT eliminates this problem entirely. IXIAN WHITE PAPER 8

11 No Proof-of-Work required: IXIAN DLT can function even with very limited processing power. The operations, which are required to validate and accept the next block, are sufficiently simple, so that even low-powered devices can participate as Master Nodes. Simplicity is achieved by moving away from the customary proof of work mining to a more efficient method of consensus. Entire wallet state is linked to the current block: Currently accepted IXIAN wallet state is a linked to the network s previous block. This way, the exact balance of all wallets is known as soon as the current state is synchronized. A unique advantage this approach offers is the ability of any user to quickly see the exact, up-to-date state of wallets, even on low-powered devices with limited bandwidth, such as mobile phones, embedded computers, netbooks, Blockchain and history In order to achieve its goals, IXIAN DLT does not store the entire history of blocks. This will be possible if nodes choose to do so, but it will not mandatory for the operation of the network. A protocol is in place to query the so-called Full History Nodes for any part of the blockchain, which will enable verification of transactions all the way back to the Genesis block. Storing history is entirely voluntary for any Master Node and is incentivized by increasing mining rewards. Several past blocks are always stored at each node. The DLT can dynamically adjust the minimum number of stored past nodes depending on network conditions, number of concurrent transactions, block size or other factors. New nodes, joining the network will synchronize the latest state with their immediate neighbors. This can be done very quickly due to the limited blockchain size. Because the entire blockchain history is not normally available, new nodes have to trust the current IXIAN DLT state. They can achieve this trust by verifying the signatures on the last valid block, which must include the network-defined minimum number of Master node signatures (initially 75%). New blocks are generated by all nodes, based on the list of known transactions at the start of the block generation cycle. These blocks are exchanged between neighboring nodes and signed until the consensus limit is reached. After that, the block is immediately accepted by the entire network. IXIAN WHITE PAPER 9

12 Included transactions Each new block includes transactions based on their timestamp value. A certain amount of drift is permissible, since the clocks cannot be synchronized to arbitrary precision, but the transaction timestamp serves as a fast, efficient initial filter. The list of included transactions in the current block can change even while processing and is only finalized after the minimum required signature number is achieved. Any transactions, which do not make it into the current block (they are not included in the accepted block) are returned to the queue and included in the next block. Thus, a possible transaction confirmation delay of one block generation cycle can occur in some cases. Invalid transactions The validity of individual transactions is checked even before they are considered for acceptance into the next block. Spending nonexistent funds or attempting to create a transaction with incorrect signature is rejected outright by any honest node and is not included in a block. If a block, containing such a transaction, arrives, the signatures on the block will easily pinpoint potentially bad (dishonest) nodes. If two otherwise valid transactions being calculated in the current block are contradictory (for example: double spending), the invalid transaction is selected by the timestamp the later transaction is dropped and the earlier one is confirmed. If the timestamps are exactly the same, the algorithm chooses the transaction with the numerically lowest TX-id to keep. With these definitions in place, all nodes can autonomously agree on which block is the correct one. Wallet state in blockchain Because the full history is normally not visible, the currently valid DLT state also contains the wallet status for all known addresses. This state is updated by each node, based on the accepted next block using a variation of the deterministic lockstep mechanism. As an implementation detail, only the checksum has to be communicated to neighbors to ensure valid state. If a node should arrive at an incorrect state checksum (compared to the majority of the network), it has to re-initialize and download the state again. This procedure is the same as when the node joins the network for the first time. IXIAN WHITE PAPER 10

13 Transaction pool and accepting the new block Transactions can be posted to any operational IXIAN DLT Node. The transaction is stored in node s local memory and communicated to its neighbors. The protocol allows for the same transaction to be communicated to several nodes at once. Each transaction is uniquely identified by a transaction identifier (TX-id). Because of instantaneous re-transmission, the transactions quickly enter the local memory storage of most nodes. At certain time intervals (currently 30 seconds, but can be dynamically adjusted by the network), the calculation of the next block begins. At this point, all nodes begin storing newly arrived transactions in a temporary area, which eventually replaces the current memory pool. Existing transaction pool is used to generate the next block. The transactions, which are put into the new block, are selected based on their timestamp, within permissible drift. Each node creates its own next block, consisting of: - Checksum of the previous block - Valid transactions for the new block - Checksum of the entire new block (including previous block s checksum) - The node s cryptographic signature of the block checksum. These new blocks are then communicated to the node s neighbors. During this process of convergence, each Node accepts blocks from its neighbors. If the received block matches the locally calculated one, the signature is already automatically correct (checksum matches). If the incoming block does not match the local one, one of the following happens: - If the incoming block has fewer transactions than the local block, no action is taken. It is assumed that the sender of the smaller block will amend its status after it receives and processes the larger block. If the local node has not yet done so, it may transmit its own version of the current block back to the sender of the incomplete block. - If the incoming block has more transactions than the local block, these missing transactions are added. The validation and signature occurs again and the amended block is transmitted to neighbors (it may be transmitted partially only the missing transactions and the new checksum+signature) IXIAN WHITE PAPER 11

14 - If the incoming block has more than the network-defined lower limit of signatures, the block is immediately accepted as valid. Transactions, which are part of the block become confirmed. The node adds its signature to the block, thus accepting its validity. The new block is written to storage and logically chained to the previous block. The valid block (with the local node s signature added) is transmitted to neighbors. (The node only needs to send the checksum and its own signature to optimize bandwidth and only provide the full block on demand.) In the event that the local node has transactions which did not make it into the valid block, these transactions are moved to the temporary area and become part of the memory pool for the next block. Next step: After a block is accepted, the wallet state is updated and becomes part of the blockchain. The temporary memory area with new transactions (and transactions, which didn t make it into the current block) becomes the new memory pool area and is re-synchronized to neighbors. The process repeats each time a new block must be generated. The interval can be dynamically adjusted by the network. IXIAN WHITE PAPER 12

15 Normal operation - graphical representation The IXIAN node is accepting transactions from clients. These transactions are immediately relayed to neighbors and thus quickly propagate through the network. At this stage, the transactions are in state pending. Figure 1: Normal Operation Diagram IXIAN WHITE PAPER 13

16 Begin new block calculation - graphical representation The node accepts the current transaction pool as valid for the next block. It generates appropriate signatures and appends them to the finished block. New client transactions are placed in a temporary area. Figure 2: New Block Calculation Diagram IXIAN WHITE PAPER 14

17 Incoming block has fewer transactions graphical representation The neighboring node has sent a signed next block with fewer transactions. The number of signatures on the new block is below minimum threshold for acceptance. The node sends the missing transactions to the neighbor, so it can update its valid block. Figure 3: Incoming Block Contains Fewer Transactions Diagram IXIAN WHITE PAPER 15

18 Incoming block contains more transactions graphical representation The new block, received from neighbor, has more transactions than the local block, but minimum signature limit has not yet been reached. The local node updates its transaction list and recalculated the proper checksums. The new transaction is also echoed to other neighbors, who have already accepted the local node s block. Figure 4: Incoming Block Contains More Transactions Diagram IXIAN WHITE PAPER 16

19 Incoming block is accepted by the network graphical representation The incoming block has enough signatures to become the next accepted block in the network. If the incoming block contains new transactions, these are implicitly accepted. If the incoming block does not contain some transactions, the extra transactions are moved to the temporary area and (later) communicated to neighboring nodes. The accepted block is immediately signed by the local node and communicated to neighboring blocks. After accepting and forwarding the new block, the local node updates its state table and verifies that it matches the checksum in the block. Then it returns to normal operation in this way, the valid next block is immediately and quickly replicated across the network and processing of blocks stops. Any transactions that weren t accepted in the current block, are placed at the top of the list for the next block. Temporary area is then used as the current memory pool storage for the next block. Figure 5: Incoming Block is Accepted by Network Diagram IXIAN WHITE PAPER 17

20 Blockchain rewards In order to incentivize block generation and running of Master Nodes, IXIAN DLT proposes two types of rewards both of which are granted to all participating Master nodes based proportionally on the amount of IXIAN in their respective wallets. - Transaction fees Each transaction in the IXIAN DLT incurs a transaction fee. The fee amount can be dynamically configured by the network based on current conditions, but hard limits are imposed for both low and high values. The fee is proportional to transaction size, but that is not a requirement of the network and can change during testing. - Flat fee On each block generation cycle, all wallets that have signed the previous block and have a certain minimum balance (e.g.: > 1000) are given a flat amount of coins. This currency is generated from nothing and provides a controlled inflation mechanism. This represents the source of income for the network. Our plan is not to introduce a final coin cap and instead control the inflation process to dynamically adapt to the conditions of the market. If a coin cap becomes required later, the flat fee can be revoked and Transaction Fee reward can remain the only income to incentivize block mining. IXIAN WHITE PAPER 18

21 Calculating the flat amount The amount of flat fee to be awarded is calculated based on the desired level of inflation. Since the inflation level is specified on a yearly basis, but awarded per block iteration, only a certain fraction of the yearly inflation amount is generated with each cycle. The exact fraction is a function of time elapsed since the start 1 of the year. Awarding The total sum of both awards is added together and distributed to all Master nodes who have participated in the previous block generation. The amount each node gets is proportional to the balance in its wallet. DLT API In order to interface with the DLT software running on a particular node, a public API has been developed and is made available to network clients based on configuration settings. A JSON-based protocol is formalized and published in order to achieve certain functionality: - Querying Node State; - Querying Network State; - Retrieving Wallet, Transaction and Block information; - Retrieving Performance counters and statistics; - Adjusting the operation of the Node; - Posting new Transactions; - Controlling the Node (shutdown, re-initialize, reconnect to network). In order to use JSON as a communication protocol, the DLT software opens a TCP port (by default listening only on the loopback interface). The binding address and port number are configurable in the software settings. 11 The start and end time of the years here only means the currency inflation cycle and does not have to align with the calendar year. IXIAN WHITE PAPER 19

22 A client, which connects to the API port will send an HTTP request with a command. The DLT software s response will be returned in a JSON document as a HTTP response. Specifications for all possible commands and their responses are published as part of the IXIAN documentation. This allows simple implementation of a GUI control application, which can run separately from the DLT service, or even in a web-based interface. In order to facilitate remote control, the DLT software only accepts commands, which originate from a non-local IP address, if they contain a valid cryptographic signature. The list of wallets, which are authorized to control the node, can be set in the configuration. Algorithms Security of IXIAN DLT largely depends on the security of the used hashing and encryption algorithms. Creating our own cryptography was briefly considered, but such an endeavor is highly discouraged without significant time and expertise in the field. We have therefore decided to use industry-standard algorithms, which are currently considered the safest. The protocol may, in the future, change these requirements if issues are discovered or computing hardware makes breaking the encryption possible. Here is a list of chosen cryptography and hashing algorithms for IXIAN DLT: - Hash (Block checksum, Transaction checksum, various handshakes): SHA256 - Signature (Transaction sig, Block consensus signature, various handshakes): ECDSA (curve: secp256k1) - Encryption: AES (Rijndael) IXIAN WHITE PAPER 20

23 IXIAN S2 Secure Streaming Network Presence List The Presence List (PL) will be the core data structure for the IXIAN network. The goal of the PL will be to store information about present nodes and clients in a form that allows efficient updates. The information stored in PL contains the following: - Node Address (Naddr) A unique address, generated by the node when it first initializes. Proposed value for this field is the node public key (wallet address). - IP Combination of IPv4/IPv6 address and a port where the node is reachable. This field may have multiple values. - Node Type (NT) A flag, indicating the type of connected node: M Master Node (manages presence list), R Relay Node, D Client, reachable directly on the listed IP, C Client, reachable through the relay node. In this case, IP field represents the relay node IP, - Last Seen Time (T) Timestamp, when the last node communication occurred. Presence List Authority Presence List will only be updated by the Master nodes. All Relay nodes will be able to obtain a current copy of the PL and keep it updated with an efficient protocol. Clients may opt to download a partial PL from Relay nodes or Master nodes. A protocol will be in place to request only specific information from the list. PL Replication between Master nodes Since Master nodes will be the only way the PL is updated, they will have to ensure fast and accurate replication of all PL changes to all online Master nodes. This will be done via a Recent Change List, which will store recent updates to the PL, as received by the specific Master Node. Other Relay or Master nodes may then specify a change id (hash) and only download updates which occurred after the specified change. If the requested change-id is obsolete (updates are no longer in the Recent Change List), the other Node must re-download the entire PL. IXIAN WHITE PAPER 21

24 Additionally, each update of the PL on a Master node will trigger a push update to other, directly-connected Master nodes. Since change-id will uniquely identify the update, it may be used to quickly discard updates which were already performed. Updating the PL relay nodes and clients Relay nodes will also have a need to update the PL. For example, on connection or disconnection of a client. The protocol will allow a Relay Node to send an update message to one or more of the Master nodes. The change will then be added to the PL and propagated between the Master nodes. A Relay Node may add records for any connected client, with the IP field set to one of its own public reachable addresses. A Relay Node can only delete or update a PL record for its own clients (clients, whose IP field has one of the reachable addresses of the Relay node). If a Relay Node would attempt to alter information, for which it is not authoritative, the change would be rejected by the Master Node. Communication Trivial case If at least one of the participating Clients is publicly connectable, the protocol will use direct connection to transfer messages. In this eventuality, no network fees should be paid. Connection through a relay If both communicating parties are unable to establish a direct connection, a Relay Node will have to be used. Transferring of messages through a Relay Node will be payable with IXIs and will represents the main network income. IXIAN WHITE PAPER 22

25 Scale-out streaming If the data transmission is intended for multiple recipients (broadcast), the procedure will be as follows: - Consumers connect directly to the Content Originator (CO). - If direct connection is not possible, or the CO reaches its transmission limit, a Relay Node is employed: o Content Originator chooses a nearby Relay Node (the choice can be random or predetermined, if the CO controls several nodes). o Content Originator begins streaming the broadcast data to the selected Relay Node. - The Presence List is updated to indicate that the broadcast stream has multiple sources. The information includes source utilization estimate. - Clients connect to the least utilized Relay to consume the broadcast. If the Relay Node is over-utilized, or the Client cannot achieve the required bandwidth, the Client may reconnect to a different Relay Node. - If the utilization of all current Relay Nodes rises above a certain threshold, the CO may add additional Relay Nodes. If the CO s outbound bandwidth is unable to support additional Relay Nodes, the broadcast may be bounced through existing Relays. - If overall utilization of the broadcast stream falls below a certain threshold, the least utilized Relay Node stops broadcasting. Stream payments: Unlike payments for direct messages, broadcast streams are charged using a different model. The initial (startup) cost of setting up Relay Nodes for the stream is paid by the Content Originator. (If CO can meet client demand without using Relay Nodes, this payment does not occur.) Streams are paid per time intervals. Clients must place funds in a stream-escrow transaction before the CO or a Relay Node will send the stream (data) to the client. After the time-period is over, the client will be disconnected, unless a new stream-escrow transaction is created. In this way, clients pay for paid broadcasts based on the amount of time they spend receiving. IXIAN WHITE PAPER 23

26 There are several methods planned to prevent abuse: - CO will encrypt the data stream and only provide keys to clients, when they pay for the first time-slot. - Relay nodes will only begin accepting and re-transmitting the stream after the startup cost is paid. - Relay nodes will track escrow transactions for their own clients in the DLT. If the escrow is not paid for the new time-slot, they will disconnect the client. - CO will pay Relay nodes according to their number of clients. If this payment is not made within a certain grace period, the Relay will terminate the stream and disconnect all its clients. - A blacklist will be built and considered for all participating parties: CO, Relay nodes and clients. Excessive errors, disconnections or non-payments will result in a network ban (either permanent or temporary). Lack of trust Because the IXIAN DLT operates on the principle of least trust, measures need to be taken to ensure honesty. The principal entities, which participate in a single message exchange are: - CS Sender (Client node) - CR Recipient (Client node) - R Relay Node - IXIAN DLT The main potential sources of dishonesty are as follows: - Relay node may attempt to claim reward without relaying the message, or may attempt to relay a garbled message to induce retransmission. - Recipient client may receive the message and not confirm receipt, in an effort to prevent the relay not from claiming the reward. In order to ensure both the correct transmission and an honest payment, several steps have to be taken. IXIAN WHITE PAPER 24

27 Proposed is one of the procedures to ensure a fair transmission and payment, although this method may be optimized or updated for the final version of the product CS Prepares the message to send and a corresponding IXIAN DLT transaction. The message is encrypted with the recipient's public key to ensure privacy. The DLT transaction is in state 'pending' (no funds are transferred until validation). The DLT transaction contains a known piece of information about the message (ie: the checksum). 2. CS contacts one of the available relay nodes in order to start transmission. 3. R generates a one-time public/private keypair (because the protection of this key only needs to last a short time, the keypair can be very short and thus generated quickly). The public key is provided to CS. 4. CS additionally encrypts the message with the provided public key. Then it generates a checksum, signing it using the same public key and appends it to the DLT transaction. The encrypted message is sent to R. 5. R can verify that the message was really encrypted using the public key it provided, since it has the corresponding private key. R can also verify that the correct signature was written to the DLT. 6. R forwards the message, the one-time public key and the DLT transaction ID to CR. 7. CR can verify that the DLT transaction originated with CS. It can show this by adding a checksum to the DLT transaction and signing it using the public key it was provided. 8. R releases the private part of the key, by providing it to CR and also adding it to the DLT transaction. 9. CR can now decrypt the transmitted message with the one-time key. Then it can decrypt the inner message using its permanent private key. 10. The nodes in the DLT network can confirm that the message transmission was completed successfully, because the transaction in the Mem Pool contains the following: a) Cryptographic proof that CS originated the transaction. 2 The method is included as a proof of concept. IXIAN WHITE PAPER 25

28 b) Signature, made with a public key from a temporary keypair. c) Confirmation of receipt, by CR. d) Private part of the temporary keypair, written by R. With the above information, any DLT node can verify the identities of CS and CR, and also the fact that the provided private key matches the public key. Because the signature in point (b) was added by CS, who is incentivized by wanting to transmit the message, this source cannot be doubted. (If CS lies, it will pay the transmission costs without actually transmitting the message.) By verifying the signature with the private key, which was added to the DLT transaction by R, the DLT node can confirm that the private key really decrypts the provided signature. R would not have added the private key, nor forwarded the message if CS attempted to lie by using a different key to encrypt the message. (R can also verify this by decrypting the outer layer of the message when it is received from CS.) CR is incentivized to provide the correct verification of receipt, otherwise R would not release the private part of the key. Because R has to append the correct key to the DLT, in order for the transaction to be fully verified, it cannot give CR the wrong key in order to try and force a retransmission. If it does, CR can simply fetch the key from the DLT network. IXIAN WHITE PAPER 26

29 Conclusion We acknowledge that this is a world of plenty, where people value (or should value) time, simplicity, privacy and security, while being socially responsible and preserving this planet. We feel that we have a unique technology for everyone and for everyday use. The technology is designed to transfer messages, money and data in a way that is easy, fast, secure and green. Our true potential is in making the technology environmentally-responsible while delivering an "IXITASTIC" experience for our users. IXIAN WHITE PAPER 27

30 References distributed-ledger-technology.pdf Working-Outage-App-Update IXIAN WHITE PAPER 28