Sunday, April 9, 2017

Running the distributed ledger queue in the sandbox

Anywhere, and everywhere place your one color ledger queue, a priced service.  Secure elements, using the system, track the current price of your set of distributed queues, the secure device will pick a queue and drop a coin for ledger service. Your service orders the queue by price, and segmented by ledger ID. Entries are taken from the top and  the appropriate ledger service called  using the appropriate ledger protocol. You can remove your coin anytime and exit the queue before service is called.

I do not see a problem when end points are secure elements obeying the rules.  There is more than one 'ledger' switch now in the market, WalMart bought one, so did the Alphabet kids.  There are more, they are neat things.

But, it brings up an interesting point.  Many coin  companies might not want you to endlessly call the null queue, just pass it from wallet to wallet.  It makes me want to define the Null Count, the number of times a coin can call the null service in sequence. The secure elements obey Null Count rule.  The default value for the default coin would have indefinite as its count, it knows no ledger service. But it is likely the Null coin ends iup being used for verification and validation anyway, thus the rules are immaterial, this is strictly forgery forensics.

The one color trades jump the boundary 

We learn interesting stuff about the sand box everyday. These ledger switches span the boundary, as will Watson, my favorite AI creature. Across the gap,smart contracts, humongous amount of efficiency to be wrought from moving mass over time and distance.  That is the heaviest ledger of all, goods fulfillment.

No comments: