polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Polygene on Blockchain
Date Mon, 23 Jul 2018 21:59:14 GMT
On Sat, Jul 21, 2018 at 3:09 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
> Gang,
>
> Roman asked about my "blockchain integration" in the "Community Building"
> thread. So, let's take some time to think about a possible abstraction.
>
> One thing that Polygene is really good at is to integrate into other
> technologies, and blockchain should not be any different.
>
> All blockchains have a few common properties;
>
>    1. A public, append-only ledger
>
>    2. Transaction-oriented
>
>    3. Delayed confirmation of transactions
>
>    4. Delayed Immutability (temporary forks exist at times).
>
>    5. Limited/expensive storage within a transaction.
>
>    6. A transaction comprises of a set of actions (or operations).
>
>    7. Addresses are used to identify accounts, transactions and other
> assets on the blockchain. Some blockchains allows for aliasing addresses
> with names.
>
>    8. All transactions require at least one private key, which is a highly
> sensitive piece of data, needs strong protection, and it must be allowed to
> make round-trips back to the client for using those private keys for
> signatures.
>
>    9. The ledger is publicly open and may be queried, often in very
> simplistic terms.
>
>   10. Blockchains emits events of what happens, but is perhaps not always
> available to receive on public REST APIs.
>
> (a few more perhaps?)
>
> Now, some blockchains have a fixed set actions available, and others allow
> for smart contracts to be uploaded. So what is common among smart contracts;
>
>     1. define new actions.
>     2. their own name spaces.
>     3. data structures, incl Map and List
>     4. has an owner who may have additional actions available
>     5. may create new smart contracts
>     6. may be delayed
>     7. actions on contract might need to be signed by user's private key
>
>
> SO, how could these characteristics boil into a Polygene abstraction for
> blockchain interactions?
>
> Well, that is the hard nut to crack, but I think we are better positioned
> to do so, than most others, as we have a great deal of "API infrastructure"
> and abstractions in place.

I think this is a great starting list!

Now that I've managed to spend a bit of time in the Enterprise Blockchain space
let me share a few observations:
   1. EOS seems to be the closest to fully realizing the vision that Blockchain
    is really a highly distributed compute platform in disguise. I
highly recommend
    reading about how they think of this problem space:
         https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
    Specifically sections on "Accounts" and "Deterministic Parallel
Execution of Applications"
    It wouldn't be a stretch to say that EOS's smart contracts are
much more of a
    lambda/serverless.

    2. I've seen a # of projects trying to simplify the job of smart
contract creation.
    Being a DSL for smart contracts if you will. However, see #1 -- I
really think
    that smart contracts are really serverless in disguise and as such
will require
    much more than a restrictive DSL. Still, the FP guys seem to be having quite
    bit of traction. A good example is here:
         http://kadena.io/docs/Kadena-PactWhitepaper.pdf

> Sure I wish I could dedicate a lot of time to this right now, but I
> can't... :-(

Well, hopefully we can just crowd-source the time ;-)

Thanks,
Roman.

Mime
View raw message