On Sat, Jul 21, 2018 at 3:09 AM, Niclas Hedhman <[email protected]> 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.
