Transledger Project (Incorruptible Distributed Smart Contract Execution/Trustless Gateways, Token Issuance/More; effectively native on RCL - Design Phase)

[jaesharp]

Okay, so I've been giving this problem some thought over the last few days and
here's what I've come up with so far.

!!!
!! This document is a draft posted for comments.
!! Please note that the "RCL TLC Implementation Protocols" section is
!! especially incomplete. This post will be edited shortly to flesh out that section with
!! more details. Eventually this document will move to a github project to manage contributions
!! by those interested.
!!
!! For now, please leave comments on content/theory only -- grammar and speeling mistaks are to be expected
!!!!

!! Note / Draft/ Conjecture

  _This proposal is (okay, it might not be, but it probably is) a nonsensical pipedream_

  The below described system is the result of my reading and synthesis of a
    number of research papers and surveys, combined with, what I hope, is
    a not overly ambitious extension of applicability and/or understanding of how those
    concepts might be applied.
    
  I am absolutely not an expert the field of mathematics -- I am certainly not an expert
    in the field cryptography. Take everything described here with a grain of salt until someone with more
    experience says that it *might* be possible. The included is pure armchair crypto design.

  Perhaps this proposal can serve as a starting point for an eventual production system.

--

# Transledger

  The "solution" (herein, Transledger or, simply, TL) is a 'batteries-included'
    suite of cryptographic primitives and protocols which when combined
    implement a globally distributed, incorruptable
    stored-program computing system.

  Such a system is, in an information theoretic sense, by construction unable to
    divulge internal state in a manor against specification and it is robust even
    to circumstances in which all agents and users of the system are arbitrarily
    corrupt themselves.
    
  An instance of the computing system and its constituent protocols, its users included, as
    a whole, are known as a TL Complex (herein, TLC).

## Problem

  Given a population of mutually distrusting users (herein, refered to simply
    as the TLC Community, TLCC; individually, a TLC User, TLCU) design a TLC
    suitable for the purpose of :

    1) Issuing and engaging in applicable lifecycle management activites of
       cryptographically verifiable assets which may be transferred and/or
       transformed via ledgers specified by arbitrarily defined protocols on behalf
       of TLCC

    2) Permits only well-defined point-in-time modification of the TLC Contract
       (herein, TLCc) subject solely due to expressed will of TLCC, the accounting
       of which must be explicitly defined in prior iterations of the TLCc.

    3) Permits the TLCC no access to any information which is not explicitly
       revealed in accordance with the TLCc, at any time; subject to certain explicit
       restrictions

  Given the above requirements, the following design constraints are implied:
 
    A) No TLCU may deviate from the protocol and remain a valid and recognised
       member of the TLCC
    
    Any deviation from protocol by any TLCU must be provably detectable by any
       other arbitrary TLCU
    
    C) Any deviation from protocol must not reveal any information to any TLCU not
       in accordance TLCc
    
    C) All TLCU Input must be encoded such that only the TLCc, when executed as a whole
       by the TLCC and given every TLCU's Input, may process said input.
       To any TLCU other than the provider of said TLCU Input, the Input must reveal nothing
    
    D) All TLCc Output must be encrypted such that only the TLCU specified in the
       TLCc may reveal it
    
    E) Zero information must be gained by any coalition of malicious TLCU from
       the receipt of suitably encoded TLCU Inputs and subsequent execution of
       the TLCc, by the TLCC, over those TLCU Inputs

    F) Zero information must be gained by any coalition of malicious TLCU from the
       execution of TLCc over received TLCU Inputs
       
    G) Zero information must be gained by any coalition of malicious TLCU from the
       despatch of suitably encoded TLCU Outputs resulting from the execution of
       the TLCc, by the TLCC, over those TLCU Inputs

    H) TLC Liveness must be preserved in the case of malicious TLCU fewer than individual
       TLC constraints (for example, malicious TLCU minority)

    I) TLC Safety must always be preserved (even in cases of malicious TLCU majority or
       unanimity)

    J) The corruption of any number of TLCU, up to and including the entire TLCC, must not
       result in the violation of any of the above constraints.

  To summarise, a computing system (TLC) to which all users (TLCC) have access to
    potentially all inputs (TLCU Inputs), the program (TLCc), its execution state,
    computational history, and all outputs (TLCU Outputs) which does not permit the
    discovery of any information specifically disclosed by the TLCc must be constructed.
    It must, by and only by its internal logic (TLCc) act as an agent in any cryptographically
    verified system and update itself as prompted by the application of the TLCc to
    instances of valid TLCC (TLCU Input) expressions.

  These requirements form the basis for which is essentially a distributed smart
    contract execution engine which can act over any number of distributed or
    centralised ledgers and which can execute arbitrary contracts, subject to
    certain practicality constraints.

## Proposed Solution

  The requirements seem impossible to meet -- the idea that, even if all
    parties are corrupted, no corruption of the system can occur is
    incredible. In the described system there is no such thing as a
    51% attack and the execution of the distributed system itself is
    sufficient proof of work. Such a system could act as an incorruptable
    agent or gateway between any N distributed ledgers or as an oracle
    relying on input from all of its users to produce change in any number
    of blockchains. The applications are nearly limitless. However, it
    sounds far too good to be true -- so we must take the default stance
    that such a system in unimplementable and/or, if it is, the constraints
    can not be guaranteed with any sound certainty. Let's try to convince
    ourselves that the null hypothesis of impossibility is wrong.

  Clearly we'll need some well characterised/proven cryptographic primitives
    and protocols with which we can implement our concept. Given the formulatic
    description of our constraints, some well selected keywords quickly hit
    on a number of subfields of cryptography. One such subfield, for a number
    of reasons, stands out immediately.

  The subfield of cryptography known as 'secure multi-party computation'
    or, simply, MPC. MPC has a rich history and provides us with a number of
    potential solutions to the problems posed by the requirements above.
    Of particular interest are the definitions of security within the field
    which we might use to enrich our own requirements:
    
    Our requirements for security in the face of malicious adversaries even
    when they are majority mean that, in the language of MPC, we desire
    "Active Security with Abort" by which is meant:
    
      > The only thing that an adversary can do in the case of dishonest
        majority is to cause the honest parties to “abort” having
        detected cheating. If the honest parties do obtain output,
        then they are guaranteed that it is correct. Of course, their
        privacy is always preserved.
          - https://en.wikipedia.org/wiki/Secure_multi-party_computation#Security_definitions

    Given that such systems have positive proofs in generality (Yao 1986),
      universal composibility (Canetti 2000) as well as, more recently,
      examples of practical application at scale (Kreuter, Shelat, Shen 2012) the field
      seems a very fertile ground for discovering cryptographic
      primitives with which we can build TL.

  Now that we have an established subfield (MPC) from which to draw primitives
    and protocols, let's assume that we're building a TLC which will interact only with the Ripple
    Consensus Ledger. Given that, we can assume the following additional characteristics:
    
    1) All TLCU will have an ordered, authenticated broadcast channel by which they may
       communicate and in which their communications are stored permanently (the RCL)
       at low bandwidth (1-2 kbps or less), at metered cost, limited total throughput and high latency (>2 s)
    
    2) All TLCU will have a mutually authenticated, possibly indirect, peer to peer channel by which they may
       communicate at high bandwidth (> 500kbps) and relatively low latency (10s to 100s of ms)
    
    3) The RCL will handle authoritative storage, transmission and exchange of all tokens issued and
       managed by the TLC and the RCL is trusted for those purposes. However, the RCL need not be strictly trusted,
       depending on TLCC desire and TLCc construction.
    
    4) The RCL serves as source of Common Reference Strings (CRS) and as such a cryptographic model
       requiring trusted Common Reference Strings may be used. However, refer (Groth, Ostrovsky 2013)

  These particular additional characteristics, when assumed by the prospective MPC system
    implementing the TLC, provide a number of additional possibilities for implementing a
    secure, scalable solution. For example, because the RCL will handle token exchange and
    management, there is no need for the TLC to execute with low cycle time. In fact,
    the execution cycle time can be up to the time required for management tasks and
    nothing else -- this is possibly on the order of hours or days, all while token
    transactions remain as quick as the underlying ledger. Additionally, The Common
    Reference String characteristic provides for the usage of models such as that
    described in (Canetti, Lindell, Ostrovsky, Sahai 2002) instead of requiring MPC developers
    and optimisers to work in only the "standard" MPC model.
 
  It's clear from the above that exploration of specific MPC implementations for
    given TLC instances will need to occur on the basis of the specific additional constraints
    imposed by the underlying ledgers on which the TLC is based. I conjecture that it's
    possible for a TLC system to be engineered without underlying ledger services, though such
    a system would be at a clear disadvantage in terms of complexity and efficiency.

  I am not qualified to select a particular implementation for the underlying system and can only guess at
    what may be possible -- a large part of why I publish this is to seek input from experts in the field
    for what may be a very real application of this technique. From my rudamentary understanding of the
    topic, and in the case of an RCL implementation, it seems very possible that the system
    as described in (Canetti, Lindell, Ostrovsky, Sahai 2002) may be a direct solution to this issue.
    
### RCL TLC Implementation Protocols

  Even though we cannot yet decide on a particular MPC implementation on which to base the
    TLC, without expert input, we can conjecture as to the nature of the protocol that
    such an implementation would follow at the layer above. So, assuming the MPC system supports
    the requirements of the TLC we can proceed based on that abstraction.

#### RCL TLCc Lifecycle Phases

##### Initialisation

  The bootstrapping phase consists of the initialisation of the MPC subsystem, selection of an initial TLCc,
    secure generation and distribution of any applicable secret key material shares.

##### Execution

  The execution phase consists of multiple executions of the TLCc according to its specific instructions

##### Transcendence

  The means by which information which is secret to any and all TLCU is transferred securely to a newly initialised
    TLCc....

## References

(Yao 1986) - How to generate and exchange secrets - DOI: 10.1109/SFCS.1986.25
(Canetti 2000) - Universally Composable Security: A New Paradigm for Cryptographic Protocols - <https://eprint.iacr.org/2000/067>
(Groth, Ostrovsky 2013) - Cryptography in the Multi-string Model - DOI: 10.1007/s00145-013-9152-y
(Kreuter, Shelat, Shen 2012) - Billion-Gate Secure Computation with Malicious Adversaries - <https://eprint.iacr.org/2012/179.pdf>
(Canetti, Lindell, Ostrovsky, Sahai 2002) - Universally Composable Two-Party and Multi-Party Secure Computation - <https://eprint.iacr.org/2002/140>

## ETC...

Per previous discussion on

tagging in @JonHolmquist@Hodor@Coroneus because they might be interested.

Edited June 27, 2017 by jaesharp
+tags

[Hodor]

I deal in "commonalities" when trying to understand a new idea. and I've read through the original thread here:

https://www.xrpchat.com/topic/6604-could-you-do-a-coin-offering-on-ripple/

From what I understand, you are planning:

• To do an ICO on RCL
• The new coin would be used to secure a network that interacts with RCL
• There is POW mining of the new coin
• The new network you are building handles smart contracts and executables in general (like Ethereum)

If I'm accurate in my understanding, or even if I'm not, I say go ahead with your plans!  I'm not a technical whiz, at least not with blockchain or POW, so I'll leave that to better minds here on the forum. 

From a business standpoint, I'd say great - try it out! 

The RCL is available for anybody to build on, and you certainly don't need permission! 

The only side note I have, and it's not a big deal at all, is "why POW?"  Ethereum is already regretting this, and is transferring to POS (a.k.a., "Casper").  Or why not a Byzantiine security model, even, with a set of validators that are rewarded based on the number of other nodes that "trust" them?  Just spit-balling, because I missed out on the initial "idea" phase, so feel free to ignore my question. 

[jaesharp]

1 hour ago, Hodor said:

I deal in "commonalities" when trying to understand a new idea. and I've read through the original thread here:

https://www.xrpchat.com/topic/6604-could-you-do-a-coin-offering-on-ripple/

From what I understand, you are planning:

• To do an ICO on RCL
• The new coin would be used to secure a network that interacts with RCL
• There is POW mining of the new coin
• The new network you are building handles smart contracts and executables in general (like Ethereum)

If I'm accurate in my understanding, or even if I'm not, I say go ahead with your plans!  I'm not a technical whiz, at least not with blockchain or POW, so I'll leave that to better minds here on the forum. 

From a business standpoint, I'd say great - try it out! 

The RCL is available for anybody to build on, and you certainly don't need permission! 

The only side note I have, and it's not a big deal at all, is "why POW?"  Ethereum is already regretting this, and is transferring to POS (a.k.a., "Casper").  Or why not a Byzantiine security model, even, with a set of validators that are rewarded based on the number of other nodes that "trust" them?  Just spit-balling, because I missed out on the initial "idea" phase, so feel free to ignore my question. 

Excellent summary, a few clarifications though:

No ICO or "premine" planned, a strict traditional capped quantity+fee model is planned for the network resource token. Further, by proof of work, I mean proof of contribution/qualification, of which the contribution consists of computing part of the next "execution slice" of the network and qualification means getting a distribution from the TLCc according to the will of the TLCC. All parties which participate in the execution slice should be compensated based on their actual contributions... none of this lottery business traditional proof of work requires (and the pooled mining it encourages). This is a hybrid model, neither pure proof of stake nor pure proof of work because we're not relying on it to do consensus - it's distribution of a token which pays for the network/contract execution and overall utility. There could be bonuses for nodes that are long lived or provide storage, etc, it's still very much an open discussion. Token consensus and transaction speed/throughput are handled by the underlying ledgers.

Finally, You haven't missed out on the idea phase, that's what this is

Edit: also, the token does not secure the network. the network is secure by construction. the token is simply a native asset which gains value based on the utility the network provides which can pay participants for their contribution to running the network.

Edited June 27, 2017 by jaesharp
clarify consensus as token consensus

[Hodor]

2 minutes ago, jaesharp said:

Consensus and transaction speed/throughput are handled by the underlying ledgers

This would qualify as an incredible innovation if you can truly make it work! 

[Mercury]

If trying something new I say go all in. I have some serious doubt about capped mined coins, when the last coin is struck the valuation for miners switches over to validating and transit fees.

I was wondering if the following might be simpler and more unique at the same time, combining mining with ripples destroying coins. Keep the new coin creation indefinitely (inflation), but have fees destroy coins (deflation). The only way to increase supply is through mining (or your proof of contribution). The increased use should destroy more coins, increasing demand. Ideally the two counter creation/ destruction mechanisms should grow with the network maintaining checks and balance without limiting supply. Early adopters wont become super rich on a decreasing supply, but the coin should remain accessible to everyone. Besides the incentive to heavily invest in mining specific hardware would be limited, preventing cartels and pools.

[jaesharp]

2 minutes ago, Mercury said:

If trying something new I say go all in. I have some serious doubt about capped mined coins, when the last coin is struck the valuation for miners switches over to validating and transit fees.

I was wondering if the following might be simpler and more unique at the same time, combining mining with ripples destroying coins. Keep the new coin creation indefinitely (inflation), but have fees destroy coins (deflation). The only way to increase supply is through mining (or your proof of contribution). The increased use should destroy more coins, increasing demand. Ideally the two counter creation/ destruction mechanisms should grow with the network maintaining checks and balance without limiting supply. Early adopters wont become super rich on a decreasing supply, but the coin should remain accessible to everyone. Besides the incentive to heavily invest in mining specific hardware would be limited, preventing cartels and pools.

That's a fascinating idea. Do you have any economic models?

Edited June 27, 2017 by jaesharp

[Mercury]

Just now, jaesharp said:

That's a fascinating idea. Do you have any economic models?

Not exactly, at least none exist to my knowledge. But we can refer to parts of existing ones.

Classical physical fiat is 'destroyed' or removed from circulation as new ones are printed. Of course the amounts are not always equal but the demand for the physical cash is tailored in part on demand.

Ripple it self as a 'pre-mined (not a really, but close enough for this illustration)' and is how bitcoin might work after the last coin is struck, with the exception of validators getting the fees instead of having them destroyed.

I suppose other models can be found in real usage, particularly in the the fields of manufacturing. More goods are created based on the demand of consumption, if consumption goes down factories go dark. I am sure if these economic aspects were searched there would be countless studies. You could borrow or refer to these 'real' world cases' as the bases. Hmmm... now that I am thinking out loud (er... typing) it might be hard to separate what 'money is' in the mind of most people (as this is not a pure monetary supply and circulation model), but rather a real life model based on everyday usage of common items.

The one thing I like is that it is not a artificial market, or at least one hard to artificially pump. The more you use the faster it destroys (increasing demand and price) BUT this also increases the rate of creation (meeting that demand).

The only thing is that maybe the rate of creation should always be a little less than the rate of destruction. This will increase the value over time and help keep the store of value aspect.  Say for every coin destroyed .95 is created and split between those who earn it it.

 

[jaesharp]

25 minutes ago, Hodor said:

This would qualify as an incredible innovation if you can truly make it work! 

Here's hoping we can. The crypto primitives I've found along with the requirements I've outlined indicate that it should be so, but the trouble is always in the details. That's why I'm opening discussions so early on this - it's new application territory; a fun and rewarding yet scary place to be. 

[jaesharp]

11 minutes ago, Mercury said:

Not exactly, at least none exist to my knowledge. But we can refer to parts of existing ones.

Classical physical fiat is 'destroyed' or removed from circulation as new ones are printed. Of course the amounts are not always equal but the demand for the physical cash is tailored in part on demand.

Ripple it self as a 'pre-mined (not a really, but close enough for this illustration)' and is how bitcoin might work after the last coin is struck, with the exception of validators getting the fees instead of having them destroyed.

I suppose other models can be found in real usage, particularly in the the fields of manufacturing. More goods are created based on the demand of consumption, if consumption goes down factories go dark. I am sure if these economic aspects were searched there would be countless studies. You could borrow or refer to these 'real' world cases' as the bases. Hmmm... now that I am thinking out loud (er... typing) it might be hard to separate what 'money is' in the mind of most people (as this is not a pure monetary supply and circulation model), but rather a real life model based on everyday usage of common items.

The one thing I like is that it is not a artificial market, or at least one hard to artificially pump. The more you use the faster it destroys (increasing demand and price) BUT this also increases the rate of creation (meeting that demand).

The only thing is that maybe the rate of creation should always be a little less than the rate of destruction. This will increase the value over time and help keep the store of value aspect.  Say for every coin destroyed .95 is created and split between those who earn it it.

 

Let's keep this in mind as we move forward. It would be good to keep a number of distribution models "on deck" - the core of the system will effectively also implement a distributed secure voting protocol (how to ensure fairness is a further discussion) so perhaps the distribution model might be dynamic acording to TLCC vote. 

Edited June 27, 2017 by jaesharp
s/system/protocol

[jaesharp]

1 hour ago, Hodor said:

This would qualify as an incredible innovation if you can truly make it work! 

Also, I should clarify that if the TL construction works the tokens will only canonically exist on RCL, just like any other IOU. In the specified system the TLC acts as sort of a virtual formally verifiable gateway/issuer - an agent acting on behalf of the TLCC, with access to the issuer keys but such that the issuer keys are accessible to none except as specified in the TLCc. It's kind of the crypto equivalent of catching your own shadow, but completely not.

Edited June 27, 2017 by jaesharp

[Coroneus]

@jaesharp, thanks for keeping me in the loop on this. I have to say that is a very detailed run-down for such a short period of time. While I don't possess the technical know-how in DLT and cryptography, I understand it enough at a business level to think of multiple use cases. I would be happy to brainstorm ideas online or offline for potential applications if/when the platform is up and running.

Edited June 27, 2017 by Coroneus

[jaesharp]

16 hours ago, Coroneus said:

@jaesharp, thanks for keeping me in the loop on this. I have to say that is a very detailed run-down for such a short period of time. While I don't possess the technical know-how in DLT and cryptography, I understand it enough at a business level to think of multiple use cases. I would be happy to brainstorm ideas online or offline for potential applications if/when the platform is up and running.

No worries. I've registered transledger.org and the transledger github project, refinement of the spec and coding of the PoC continues in force this weekend.

Edited June 28, 2017 by jaesharp

[thinlyspread]

On 6/27/2017 at 3:40 PM, jaesharp said:

Excellent summary, a few clarifications though:

No ICO or "premine" planned, a strict traditional capped quantity+fee model is planned for the network resource token. Further, by proof of work, I mean proof of contribution/qualification, of which the contribution consists of computing part of the next "execution slice" of the network and qualification means getting a distribution from the TLCc according to the will of the TLCC. All parties which participate in the execution slice should be compensated based on their actual contributions... none of this lottery business traditional proof of work requires (and the pooled mining it encourages). This is a hybrid model, neither pure proof of stake nor pure proof of work because we're not relying on it to do consensus - it's distribution of a token which pays for the network/contract execution and overall utility. There could be bonuses for nodes that are long lived or provide storage, etc, it's still very much an open discussion. Token consensus and transaction speed/throughput are handled by the underlying ledgers.

Finally, You haven't missed out on the idea phase, that's what this is

Edit: also, the token does not secure the network. the network is secure by construction. the token is simply a native asset which gains value based on the utility the network provides which can pay participants for their contribution to running the network.

Sorry for this 2017 "necro" but this is now relevant again today, and I am even wondering if the author is now working at or with Flare Networks...  

I cannot help but be impressed with the vision herein and uncanny similarities to what Flare is setting out to do – after all these years... brilliant. 

@jaesharp are you still a visitor here? If so, are you still working within the XRP/crypto ecosystem? Are you aware of Flare etc?