The secure memory, data and code, is a separated address map and sandbox transactions get routed to the secure element. So, the very few rules in the sandbox can be enforced in the secure element on the device.
No one gets access to the code and data except support for a spreadsheet functionality in the element. You can forget the words host and emulation. Instead call it the pure cash flow manager, it should be able to hold currency.
So far, so good, step one, step one is the hardest.
Next we get the ledger functionality then functionality to understand compressed prices. The pits will quickly adapt to auto trade in response to endpoint security.
I want this thing on a plastic card with all other parts of the smartphone gone, except red/green. And we need some private key distribution in the secure element.
A world of honest spreadsheets, built around double entry accounting.
They all talk to each other and ,manage their own network congestion management. Built, optionally, over tcp/ip, It has to at least hold number IP addresses. I dunno i we get an IP layer under NFC, I haven;t looked, it is immaterial.
In my model,the secure element never access the 'web' directly, only through apps on the persona; computer. The secure element should not even use the URL server. The secure element does not open car doors or drive robots. It only talks to other secure elements, pair wise or pit wise.
It is strictly a partially shared spread sheet. Always, everywhere, price sequences are compressed into a contracting distribution to capture significant trades first. By contracting I mean spanning tree with no loops generates the typical sequence. Thus, arrival uncertainty is a containerized system.
No comments:
Post a Comment