2017-07-31

« »

Privacy & Privity

Askemos has no unnecessary global sharing of data: only those parties with a legitimate need to know can see the data within an agreement. AVM has a well defined set of “notaries”. A “notary device” or “notary node” is any node commissioned to support a particular agreement (a.k.a “AVM” in the Askemos model.).

Askemos achieves consensus between firms at the level of individual contracts, not the level of the system.

Multiple implementation are possible (like BALL, our prototype). Those organize the workflow between participants without a central controller.

Askemos enables regulatory and supervisory observer nodes; regulatory and supervisor nodes are just regulated “notaries”.

Askemos transactions are validated by parties to the transaction rather than a broader pool of unrelated validators. Logical objects (“AVM” or “place” in traditional Askemos language) are validated by notary nodes commissioned to validate the AVM. These nodes are normally provided by the parties relevant to the agreement. That includes actual parties, chosen witnesses and possibly supervisory observers.

Auditible and Controlled by Humans

Askemos strongly suggest to maintain an explicit link between human-language legal prose documents and smart contract code. In the Askemos model we see the human-language readable document as the legally binding part, while the machine readable part is just factually binding. Conflicts need to be resolved at an upper layer, typically by humans.

Consensus and "Booked Memory"

The first, and most important, feature of Askemos is that it create a world, the "booked memory" it is, where parties to a shared fact know that the fact they see is the same as the fact that other stakeholders see:

“I see what you see… and I know that what I see is what you see”

And, critically:

“I know that you know that I know”!

...And it does this between mutually distrusting parties. However this does NOT imply that a third party can learn aout the shared fact. consensus occurs between parties to the deal, not between all participants of the system.

So much for the core idea of Askemos: replace the server side of the Internet with a network of interacting caches. Teach the caches to handle updates to the common, known-to-be-known, memory. Booked memory as in facts we have in our books. Never ever let those “caches” in need to access the origin server. Now take the server out of the picture. They are now purely virtual in common knowledge.

Validity

Interwoven with consensus, audited evaluation allows us to decide whether a given proposed update to the system is valid. In the Askemos model each AVM has an immutable property: the contract (human and machine readable code) which defines the rules of the game how the state is to be revealed and changed.

This is how we define the rules of the game. What does a valid “fact” look like in the system? What does a valid update to that fact look like?

Minimal

Askemos is minimal. It does not contain any features unrelated to the business case. For instance there is no native cryptocurrency.

proof of work is unnecessary and even counterproductive for private deployments

What we Pick from prior work

Askemos core structure is influenced by Erlang/OTP. This buys us proven concept, the "actor model", to create distributed systems which need to graceful degrade when the network is partitioned. From L3 we take the idea that processes can be persistent even over a system reboot. From functional programming we take immutable data and store this in immutable "booked memory" (a.k.a. or these days "blockchains sans native crypto currency" - though these are not a prior work to Askemos). From Scheme we take a minimal initial language which we use to update shared state in booked memory. From state machines replication we take the concept byzantine consensus about shared facts. Finally we recognize the concepts "privity and privacy" and conclude to distribute shared facts precisely to parties relevant to the fact and possibly witnesses deliberately chooses by those parties.


« »

2017-11
2017-10
2017-07
2016-07
2016-06
2016-05
2016-03
2016-02
2015-11
2015-10
2015-08
2015-01
2014-11
2014-09
2014-08
2014-07
2014-06
2014-05
2014-04
2014-03
2014-02
2014-01
2013-12
2013-11
2013-10
2013-09
2013-08
2013-07
2013-06
2013-05
2013-04
2013-02
2013-01
2012-12
2012-11
2012-10
2012-09
2012-08
2012-07
2012-06
2012-05
2012-04
2012-03
2012-02
2012-01
2011-12
2011-11
2011-10
2011-08
2011-07
2011-06
2011-03
2011-02
2011-01
2010-12
2010-11
2010-10
2008-07
2006-09