AliceChain (2022-05-30)

AliceChain is a proposed architecture for a universal system of decentralized credit.
Our mission is to remedy the shortcomings of legacy systems by establishing a laissez-faire ecosystem of tradable value to eventually form the foundation of a universally accessible financial operating system.
This document provides a technical overview of the problems we are attempting to solve and our strategies to solve them.

AliceChain is a work in progress and is subject to change.
AliceChain is created for the public benefit, but assumes absolutely no liability, and does not claim to provide professional advice in any capacity.
AliceChain is forever dedicated to the public domain.

Table of Contents

Context

We make the following basic assumptions about a generic entity named Alice:

  • Alice seeks to obtain some desirable thing.
  • Alice depends on other entities to provide some services.
  • Alice can freely interact with other entities.
  • Alice can locate entities that claim to provide services she depends on.
  • Alice can trust some of those entities to provide services to her satisfaction.
  • Alice can exchange something of value to those entities for their services.

Alice requires a system that best facilitates her to obtain the thing she desires given these basic assumptions.

Legacy Systems

A direct approach is for Alice to physically exchange things she has for things she wants on mutually agreed terms; namely, a system of barter.
This system has several drawbacks:

  • There may be a significant cost to store, maintain, and transport large quantities of physical items. In some cases, Alice may not even have the knowledge nor resources to physically handle the items she would trade for.
  • Some physical items cannot be easily divided, if at all. For example, while it is easy to divide a block of cheese, it is not possible to meaningfully divide a live horse.
  • Alice may not always have what the other entity wants, even though the other entity has what Alice wants.
  • Alice must have some level of trust in the entities she deals with. It may become difficult for Alice to establish trust with an ever increasing number of independent entities.
    Thus, larger scale operations will inevitably require a more effective system.

If Alice trusts a service provider named Bob, then Alice can value a system of credit maintained by Bob.
Alice can exchange something of value for Bob's credit, because Alice trusts Bob to eventually provide his service in exchange for it.
Bob's credit is an indirect numerical representation of value, backed by Alice's faith in Bob, as opposed to a direct physical manifestation of value.
These representations of value are immensely more convenient to handle than their physical counterparts, especially in the context of the modern age with the ubiquity of sophisticated computing devices connected to a global Internet.

In practice, current credit systems are made to be somewhat restrictive:

  • Accounts with credit usually cannot directly transfer credit to other accounts on the same system, let alone other systems.
  • Arbitrary limits are sometimes placed on the amount of credit an account can hold, and for how long.
    The fundamental role of credit storage and transferral is instead conceded to dedicated banking institutions, which are unfortunately far from ideal in the modern age:
  • The process of accessing these services is unnecessarily complicated and demanding.
    In particular, banks are required to verify extensive personal credentials, such as sensitive personal information, government-issued identification, proof of address residency, and the like, in order to open a bank account.
    Online platforms are also required by banks to have users who receive payments provide similar personal credentials.
    These requirements unnecessarily exclude a significant portion of users, such as:
    • Users who are unwilling to reveal personal information.
    • Users who simply do not possess the required credentials.
    • Users dealing with unresolvable complications with the agencies involved, sometimes out of their control.
    • Victims of identity theft.
      We contend that there should not be a requirement for these kinds of personal credentials in the economic dealings between independent entities in the first place.
  • Banks place arbitrary limits and delays on payments and otherwise.
    We contend that independent entities should not be forcefully limited by the policies of a third party entity in this way.
  • The security model of payment processing is severely outdated.
    Payments are typically authorized by the mere provision of credit or debit card details.
    These details can be misused by a malicious service provider, or a malicious intruder of a service provider's databases.
    A system based on public key cryptography would provide more security in this regard.
  • Transactions can be reversed at the bank's sole discretion.
    Customers can initiate a chargeback on most transactions at their sole discretion, and this process is made to additionally punish service providers financially and reputationally.
    In particular, a chargeback on a service that is provided digitally will generally not end in the service provider's favor.
    Although chargebacks can be legitimate, we contend that the customer should not be treated like they are eternally right.
  • Accounts can be frozen at the bank's sole discretion.
    Banks who unrightfully restrict accounts in this way face no real consequences for doing so, other than an upset minority of affected users.
  • The currency supply can be inflated at the central bank's sole discretion.
    Central banks who irresponsibly inflate the currency supply will inevitably devalue the currency, and face an upset majority of affected users.

Blockchain systems, such as bitcoin, have recently emerged as a response to a growing dissatisfaction with centrally governed currency systems.
These systems seek to eliminate the role of a centrally governing body altogether, through careful utilization of cryptography and a network of independent participants collectively governed by a decentralized consensus algorithm.
Although these systems theoretically remedy much of the aforementioned problems, they are encumbered with significant drawbacks in practice:

  • "Proof-of-work" decentralized consensus algorithms foster economic incentives for colossal amounts of computational work, and therefore energy consumption. Even if implemented in a sustainable manner, we should not overlook the sheer volume of dedicated equipment and energy that must be invested into the continued maintenance of these systems.
  • It usually takes a significant amount of time, typically on the order of minutes, to confirm a transaction. While minutes may not constitute an unbearable amount of time in many cases, it is still a noticeable inconvenience and a great shame when data can be transmitted across the globe in a matter of seconds, if not milliseconds.
  • Participants are required to download and process the entire blockchain to independently validate the legitimacy of transactions. For example, the total bitcoin blockchain size exceeds 400GB at the time of writing, and will only increase with time. A significant portion, if not the vast majority, of users find it more practical to instead rely on some form of custodial service of the blockchain system on their behalf, which defeats the foundational purpose of the system for those users in the first place.

We contend that these legacy systems hinder potential innovation in the modern age.

Decentralized Credit

The drawbacks associated with blockchain systems arise from the excessive overhead of decentralized consensus algorithms.
The purpose of these algorithms is to enable independent entities to reach a trustless agreement about an immutable chain of events.
We contend that this approach is fundamentally overreaching for our purposes.
Instead of having independent entities strive to maintain a single chain of events, we devise a system where independent entities each maintain something of their own, yet are able to cooperate in some meaningful way.
Figuratively speaking, instead of having Alice and Bob strive to maintain a single "AliceBobChain", we have Alice solely operate an "AliceChain" and Bob solely operate a "BobChain".
To emphasize our departure from the "AliceBobChain" approach, the project as a whole is named AliceChain.

A chain is an independent system of credit, where a chain operator can assign credit to anyone, and a holder of credit can reassign the credit he holds to anyone.
A chain operator promises to provide some valuable service to those who spend credit on his chain.

The actual value of a chain's credit hinges on the condition that the chain operator continues to provide his service, despite there being nothing that intrinsically forces him to.
If he fails to keep his promise for whatever reason, then holders of credit on his chain will have lost some or all of whatever value they exchanged for it, as credit by itself holds no intrinsic value.
Our system is therefore not trustless, but we contend that a trustless system of currency is ultimately meaningless without the need to eventually trust someone to provide some valuable service in exchange for that currency.
We build upon the requisite trust that must have been established to begin with.

If Alice and David trust Bob and Carol, then Alice and David can perform a trade of credits on Bob's and Carol's chains without the need for Alice and David to trust each other, nor the need for Bob and Carol to trust each other.
Alice can therefore distribute the total value of her held credits across as many chains as she wants, and does not need to trust any entity that she doesn't already trust to begin with.
This unrestricted interplay between independent chains and holders constitutes a system of decentralized credit.

Decentralized credit is not a guaranteed long-term store of value, but we contend that proper utilization of a prospering ecosystem gives it the potential to become one of the most efficient stores of value in the modern age.

Protocol

Independent entities in our system adhere to a protocol that is objectively reasonable to everyone involved.

A credit is a data structure that represents the assignment of credit to a holder.
When Bob wants to assign credit to Alice, he signs and transmits an appropriate credit to her.
A credit specifies Alice's public key, the credit amount, and a salt value.

A contract is a data structure that represents the reassignment of credit from one holder to another.
When Alice wants to reassign credit assigned to her on Bob's chain, she signs and transmits an appropriate contract to Bob.
A contract specifies input credits assigned to Alice, Bob's signatures of those credits, the public keys of whom to reassign credit, the credit amounts, and salt values.
Bob is required to provide a valid response to a valid request, and is allowed to ignore invalid requests, such as contracts that do not supply enough input credit amounts.

To give a concrete example, we will assume that Alice produces almonds and Bob produces books.
Alice and Bob reach a mutual agreement to trade Alice's almonds for Bob's books.
Bob eats Alice's almonds faster than Alice reads Bob's books, so Alice is eventually able to give more almonds than she wants actual books.
Alice trusts Bob, so she agrees to trade her almonds for credit on Bob's chain.
Alice generates a random salt value and transmits it to Bob, who is expected to use it when transmitting a credit to Alice, in order to be reasonably assured that Bob is not simply reusing an old credit.

We will assume that Carol produces carrots.
Carol wants Bob's books, but Bob does not want Carol's carrots.
Alice wants Carol's carrots, but Carol does not want Alice's almonds.
However, Alice has Bob's credit.
Alice and Carol reach a mutual agreement to trade Bob's credit for Carol's carrots.
Alice submits a contract to Bob, which inputs the credit she previously received and reassigns some credit to Carol, along with a salt value that Carol specifies.
Bob is required to reply with the specified credit assigned to Carol, along with remainder credits back to Alice.
Carol then submits a contract to Bob, which inputs the credit assigned to her and reassigns some credit back to Bob.
Bob is required to reply with remainder credits back to Carol, and is expected to provide his books as promised.

In our system, signatures represent irrevocable intent.
If private keys remain private, then only Bob can assign credit on his chain, and only Alice can authorize the reassignment of credit assigned to her on Bob's chain.

As Bob solely operates his chain, he has the option to maliciously target Alice and intentionally neglect any contract she submits, effectively "freezing" credits assigned to her on his chain.
This act of delinquency cannot go unnoticed by Alice, as Bob will never have a legitimate reason to not provide a valid response to a valid contract.
However, Bob cannot prevent Alice from broadcasting contracts he neglects to other holders of Bob's credit, where concerned entities can independently submit the contracts for themselves.
If Bob continues to neglect Alice's contracts, then Bob's rational patrons will eventually lose any reasonable trust in him, and be strongly compelled to take their business to his competitors.
In other words, if Bob attempts to neglect Alice on his chain in this way, then he equips Alice with undeniable evidence of his delinquency that can ultimately result in the demise of his business, one that he may have heavily invested in to establish in the first place.
Therefore, a rational Bob driven by self-interest and loss aversion will choose to avoid this situation entirely.

Bob is not required to process a contract that contains an input credit that was already processed in a previous contract, in order to prevent the arbitrary inflation of credit.
If Alice submits such a contract, then Bob is allowed to instead reply with the previous contract.
Thus, Bob is compelled to store all the contracts he ever processed on his chain, despite not having an unlimited amount of space to store them in.
Thus, contracts must incur a contract fee, which is the canonical amount of bytes required to store the contract.
Thus, the promised value afforded by a certain amount of credit is inherently tied to the cost of indefinitely storing a comparable amount of bytes.

A typed credit is a credit that additionally specifies an arbitrary string as a credit type, the exact meaning of which is specified by the chain operator.
Typed credit amounts are not tied to the cost of contract storage, but they must be accompanied with normal credits to pay for contract fees in contracts that input them, where a normal credit is one that has no credit type.
For example, if Bob were to also provide boats in exchange for normal credits, then he must demand a much higher credit amount than he does for books.
Thus, the total amount of credit in circulation must increase if anyone is to ever redeem boats in this way.
It is not a violation of the protocol for someone who holds a large amount of credit to submit an excessive amount of meaningless contracts to purposefully exhaust storage space on Bob's chain.
Instead, Bob specifies that his boats can only be redeemed with credits of the "boat" credit type, along with normal credits to pay for contract fees.
This mechanism deflates the demand for Bob's normal credit, and thus the total amount of normal credit in circulation, and thus the total amount of storage space that Bob is ultimately accountable for.

Holders may wish to trade the credit of different chains.
Without the ability to specify more than one chain in a contract, one must reassign credit on one chain without any assurance that the other will reassign credit on the other chain, or rely on an additional trusted party to provide an escrow service.
A dual-chain contract is a contract that specifies the simultaneous reassignment of credit held by two different holders on two different chains, allowing trades of credit between them to require no additional trust.

Our protocol must ensure that each holder will always be able to receive either the requested credit or a refund of the provided credit in a trade, and that each chain will never need to assign more credit than was inputted, even if all other entities in the interaction coordinate a deliberate effort to produce a result to the contrary.
Each holder signs and submits the contract to his respective chain, where the chain processes only its half of the contract, and is required to respond with a Contract Signature and remainder credits, or a previous contract that spent any of the input credits.
Each holder requests the other holder to provide a Contract Signature for the other chain.
A holder can cancel the trade on a chain by submitting a Contract Signature and a Holder Cancel Signature, where the chain is required to respond with a Cancel Signature, or a Contract Signature for the other chain.
When a holder submits a Cancel Signature to a chain, the chain is required to respond with credit assigned back to the original holder.
A holder can lock the trade on a chain by submitting both Contract Signatures, where the chain is required to respond with a Lock Signature, or a Holder Cancel Signature and a Cancel Signature.
A holder can commit the trade on a chain by submitting both Lock Signatures, where the chain is required to respond with credit assigned to the intended recipient, or a Holder Cancel Signature and a Cancel Signature for the other chain.
A holder can revert the trade on a chain by submitting a Lock Signature, and a Holder Cancel Signature and a Cancel Signature for the other chain, where the chain is required to respond with credit assigned back to the original holder, or a Lock Signature for the other chain.
The contract fee for a dual-chain contract includes the additional space required for the various signatures that must be stored to meet these requirements.

If handled properly, a holder will never lose more than the contract fee due a failed trade.
It is imperative for chains to value their units of credit in such a way to minimize the perceived losses from contract fees.
For example, losing 100 units from a contract fee will be much more significant if an entire book costs 100 units, than if a book costs 100,000 units.
Ideally, the perceived loss from the contract fee due a failed trade should be insignificant compared to the time and energy expended to find and conduct the trade in the first place.
Therefore, trades are not entirely trustless, but a failed trade will always be a "bump in the road" and never a "fatal car crash".

Ecosystem

The practical utility of AliceChain is inherently tied to the prosperity of its ecosystem.
We contend that AliceChain exhibits properties of a self-propelling system, where rational participants driven by self-interest are individually compelled to contribute to the ecosystem when left to their own devices.

  • A primary service provider provides some valuable service in exchange for credit on a chain it directly operates.
    Primary service providers are relied upon for their continued operation.
    Compelled by profit margins, primary service providers form a foundation of practical value in the ecosystem.
  • A secondary service provider provides some valuable service in exchange for credit on a chain it does not operate.
    Secondary service providers can potentionally come and go with less consequence than primary service providers.
    Compelled by profit margins, secondary service providers augment practical value to the ecosystem.
  • A holder, also informally called a small fry, holds and spends credit for its practical utility.
    Holders can engage with the system carrying no inherent responsibilities to other entities.
    Compelled by their own desires, holders influence the demand for services.
  • A collector, also informally called a whale, collects an appreciable amount of credit on many chains.
    Collectors can profit from trading when the collector has credit on a chain that another entity wants but does not have.
    Compelled by profit margins, collectors expedite the interchangeability of credit between independent chains.

An adequate amount of healthy demand for services will result in the natural emergence of service providers.
An adequate amount of healthy competition between service providers, and between collectors, will result in profit margins that befit the natural law of supply and demand.

TBD?

Implementation

A prerequisite for this ecosystem is the availability of mutually compatible impilementations.

TBD... the rest of this section is rambling

baseline functionality

Insecurity of "Web Public Key Infrastructure"

The current state of the art is unnecessarily mired by countless standards, conventions, protocols, workarounds, and revisions.
We design a system from the ground up to achieve the system we require.

We make absolutely no attempt to provide backwards compatibility for any of these legacy methodologies.
AliceChain must coexist with them until they eventually become obsolete.

dependencies:
unix-like system library (file i/o, sockets, poll)
nettle
ncurses
SDL

Internal Database

TBD

Channels

TBD

Sanitized Applications

TBD

Example Applications

TBD

Vulnerabilities

TBD

cryptographic security
side channel attacks
network denial-of-service

secret management
backup management
trust management
audit management
identity management

Roadmap

The following roadmap outlines the gradual integration of AliceChain into the economic fabric of mainstream society, recognizing five main eras of societal adoption:

  1. Conceptual
    The start of this era is marked by the publicization of a reference implementation.
    AliceChain is largely unknown, untrusted, and unutilized at this point.
    AliceChain will not yet appeal to the herds of society who are attracted to flashing lights and social hype; rather, it will generally only appeal to the curious intellectuals who will understand its potential for society.
    The primary strategy of this era is to create, disseminate, and promote educational content.
    The primary goal of this era is to establish a "hundredth monkey effect" of recognition.
  2. Inconsequential
    The start of this era is marked by the emergence of inconsequential primary service providers.
    These services generally do not provide practical utility.
    Example services include demonstration applications and simulations of consequential services.
    The primary strategy of this era is to support the endeavors of the technically inclined.
    The primary goal of this era is to establish a vibrant proof of concept ecosystem.
  3. Consequential
    The start of this era is marked by the emergence of consequential primary service providers.
    These services provide practical utility restricted to the virtual world.
    Example services include online games, video hosting services, and cloud hosting providers.
    The primary strategy of this era is to foster a demand for existing service providers to adopt AliceChain.
    The primary goal of this era is to establish an ecosystem with practical utility.
  4. Material
    The start of this era is marked by the emergence of material primary service providers.
    These services provide practical utility applicable to the real world.
    Example services include ridesharing, food delivery, and provision of physical items.
    The primary strategy of this era is to participate in the consumption and trading of these services.
    The primary goal of this era is to establish AliceChain as a viable alternative to fiat currency systems.
  5. Official
    The start of this era is marked by the recognition by official technology and governmental agencies.
    AliceChain cannot be stopped nor ignored by the world at this point, as official implementations and services emerge.
    The primary strategy of this era is to expedite the transition from legacy systems to AliceChain on a global scale.
    The primary goal of this era is to establish AliceChain as the official foundation of a universally accessible financial operating system.

The current state of progress will be summarized in the companion document COMMUNITY.md.

Philosophy

Those whose values align with our philosophy will likely find the most benefit in the prosperity of AliceChain.
In no particular order:

  • Self-Sufficiency
    We actively seek to remove the middle man whenever we reasonably can.
    When we cannot, we prefer the option of less reliance.
  • Laissez-Faire
    We do not unreasonably impose onto others, and we do not allow others to unreasonably impose onto us.
    In other words, we actively seek to live and let live.
  • Caveat Emptor
    The buyer and the buyer alone is responsible for the buyer's actions.
    If we make a choice that we regret, then there is nobody coming to save us.
  • Privacy
    The concealment of information does not always have illicit motives, as sometimes it is a defense against them.
    We do not require others to reveal more than what is necessary.
  • Clarity
    Concepts must be readily understandable.
    We explain with the goal to be fully understood by the person who initially knows nothing about what we seek to explain.
  • Minimalism
    We actively seek to remove components that are recognizably unnecessary.
    Our systems remain compact as a natural result, not because compactness itself is the end goal.
  • Resilience
    Our systems mean nothing when they fail to work as intended.
    We actively seek to remedy and prevent systematic failures which are not outside of our control.
  • Practicality
    Our goals mean nothing if they cannot be realistically achieved.
    We are willing to sacrifice ideality for practicality whenever necessary.
  • Adaptability
    The proper response to a problem that adapts is a solution that adapts.
    We design systems that adapt to the ever-evolving requirements of its users.
  • Modernity
    We design novel systems for the present and future.
    We are willing to sacrifice legacy systems of the past.
  • Inclusivity
    The more the merrier.
    We actively invite the general public to learn about and use our systems.
  • Public Domain
    We create systems for the sake of their creation.
    We find no detriment to explicitly allow their unrestricted use.
Edit
Pub: 30 May 2022 11:21 UTC
Views: 634