polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Polygene on Blockchain
Date Sat, 21 Jul 2018 10:09:04 GMT

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

   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.

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

Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message