Post on 28-Jul-2020
IXIAN WHITE PAPER
1
Technical White Paper
www.ixian.io hello@ixian.io
IXIAN WHITE PAPER
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 www.ixian.io/whitepaper
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 1
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 ........................................................................................................................ 10
Invalid transactions ........................................................................................................................... 10
Wallet state in blockchain ................................................................................................................. 10
Transaction pool and accepting the new block ................................................................................ 11
Normal operation - graphical representation .................................................................................. 13
Begin new block calculation - graphical representation ................................................................. 14
Incoming block has fewer transactions – graphical representation ............................................... 15
Incoming block contains more transactions – graphical representation ....................................... 16
Incoming block is accepted by the network – graphical representation ........................................ 17
Blockchain rewards ........................................................................................................................... 18
Calculating the flat amount .............................................................................................................. 19
Awarding ............................................................................................................................................ 19
DLT API ............................................................................................................................................. 19
Algorithms .......................................................................................................................................... 20
IXIAN S2 – Secure Streaming Network ............................................................................................... 21
IXIAN WHITE PAPER 2
Presence List ...................................................................................................................................... 21
Presence List Authority .................................................................................................................... 21
PL Replication between Master nodes ............................................................................................. 21
Communication .................................................................................................................................. 22
Scale-out streaming ........................................................................................................................... 23
Stream payments: .............................................................................................................................. 23
Lack of trust ....................................................................................................................................... 24
Conclusion ............................................................................................................................................... 27
References ................................................................................................................................................ 28
IXIAN WHITE PAPER 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
- 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 13
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 14
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 15
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 16
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 17
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 18
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 19
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 ‘start1‘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 20
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 21
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 22
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 23
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 24
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 25
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 product2.
1. 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 26
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 27
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 28
References
https://en.wikipedia.org/wiki/Blockchain
https://en.wikipedia.org/wiki/Distributed_ledger
https://en.wikipedia.org/wiki/Cryptocurrency
https://bittrex.com/
https://en.wikipedia.org/wiki/Cryptocurrency
https://techcrunch.com/2017/04/12/messenger/
http://www.statisticbrain.com/skype-statistics/
http://expandedramblings.com/index.php/twitch-stats/
http://expandedramblings.com/index.php/whatsapp-statistics/
http://expandedramblings.com/index.php/how-many-people-use-chat-apps/
https://ring.cx/en/news#release-of-ring-10-liberte-egalite-fraternite
https://en.wikipedia.org/wiki/BlackBerry_Priv
https://blockchain.info/charts/blocks-size
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-
16-1-distributed-ledger-technology.pdf
https://www.quora.com/Why-isnt-the-size-of-the-blockchain-a-serious-problem-for-Bitcoin
http://www.dailystar.co.uk/tech/news/465903/SKYPE-DOWN-popular-messaging-service-
offline-across-globe
http://www.express.co.uk/life-style/science-technology/800092/WhatsApp-Down-Not-
Working-Outage-App-Update