References

The Problem: Trust is Low

The Beatles song from 1968: Strawberry Fields defines the problem > "Nothing is Real"

i>> With our connected world, the problem of what's true and trust have increased a 100 times compared to life 200 years ago

200 years ago, the only things you couldn't verify with your 5 senses easily were God, the Devil and germs

Today, what CAN you verify 100% even if you use your 5 senses?

Re-imagine DLT as STS - Smart Trust Services

can be implemented, consumed & operated as platforms, services, capabilities, features, components, extensions, integrations, interoperable communications

1. solutions - 
   1. ssi, did, vc, crypto, digital assets life cycle, custody, trading, markets, security, audits, surveys, 
2. capabilities – can be engineered as features of, integrated with, extensions of or interoperable with: other solutions and services
   1. verifiable history, counter-party trusts, identities, credentials, signatures, contracts, governance, consensus, policy management, trades, payments, proofs, votes, pogs, non-repudiation, tamper-proof, fault-tolerant system of record, faster reconciliations on proofs with chains, access controls (keys, ZKP ), observability & audits, version management 
3. services - smart trust services, like others, are composable
4. platforms – platforms partially implement capabilities
   1. DLT:  Fabric, Indy, Aries, Besu, Polygon, Corda, Firefly, DAML, 
5. technologies - technologies supporting STS
   1. encryption, secrets, mpc, confidential compute, wallets, signatures, tokens, ACID transactions, AI, analytics, DLT, cryptography, data management, learn, MDS - metadata services, Doc services ( see plantuml ), GEMS ( Apache Mesh ), distributed data, 
6. models & patterns
   1. async events ( GEMS ), CQRS, views, streams, workflows, replicas, replay, recovery, resiliency, GPMS, 

Blockchain has some features that can add value to STS 

s Enterprise Blockchain Concepts and Value# BUSINESS VALUE IMPACTS POSSIBLE with Blockchain

m TOIP Trust Over IP# Key DLT features create a proof system

Blockchain has limitations that STS should avoid

s Enterprise Blockchain Concepts and Value# Blockchain Challenges

STS Assessments

Key Questions 

1. What is the use case in scope?
2. Who are the parties, roles and goals?
3. What are the parties relationships, counter-party challenges?
4. What are the operations and processes?
5. How are DATES defined and used in the solution 3P ( policies, procedures, processes ) now?  ( Decisions, Automations, Trusts, Events, Services )
6. What are the proofs needed? Why? How?
7. FACTUR3DT.i without STS
8. FACTUR3DT.o with STS

Key Points

SLT:DS features and capabilities

1. It's not DLT ( or DAML or Corda or ?? )
2. has specific features for specific value impacts
3. goals include: separation of producer / consumer roles in data services, add only key proofs to create trust for given use cases
4. produce effective trust service models
5. provides full ACID support
6. favors throughput ( TPS ) over latency ( time to commit, finalization )
7. favors async over sync processing where possible to improve throughput
8. implements specific patterns to address specific problems for selected use cases
9. intended to support VCE: Value Chain Economies for identified parties, governance and compliance services
10. governance is independent of the technology
11. deployment topologies are independent of the technology
12. applies Trust engineering principles to deliver specific trust benefits not covered by Distributed DBs
13. avoids some DLT features that limit performance and scalability or adds strategies to manage those challenges
14. rethinks transaction life cycle and events as:  request, capture, validate, process, approve, commit, finalize, response  
15. leverages open-source solutions wherever feasible
16. uses interfaces and adapters to support multiple implementations of a feature with default implementation as an executable example
17. uses adapters, containers and wrappers to minimize direct dependencies on 3rd party components and services
18. minimizes cloud specific dependencies on client interfaces ( high priority ) and implementations where feasible
19. support zero trust security where feasible
20. support private, shared, aggregated data objects, messages and streams
21. support data encryption in flight, at rest, in compute where needed
22. leverages user defined policies to control design, development, test, deployment, operation and support where feasible
23. maximizes performance for write and read use cases for high throughput transaction tables
24. uses key - value stores for text, blobs for fast write for big data tables in addition to RDBs
25. supports generated UIDs, primary auto-gen numeric or character format surrogate key IDs for primary keys with timestamps 
26. uses control tables to: create control blocks of related transaction records for data updates, transaction status
27. uses control tables for data rollback, replay by table segment as needed
28. uses data hashes to link transactions to improve tamper-resistance and data provenance
29. data distribution to nodes: uses archivers and relayers to move data blocks from local to remote nodes
30. provides directory services to search and locate data based on metadata 
31. provides sharing data blocks using efficient protocols:  simple gossip, protobufs etc over VPN or MTLS connections
32. uses shards when needed to speed search and improve data obfuscation when configured in policies
33. provides client access support using compatible JDBC, ODBC, APIs, grpc and message interfaces when possible
34. provides dynamically configurable logging capabilities based on information levels
35. supports memory caches configurable for performance use cases
36. provides processing priorities for different threads ( real-time vs batch ) to maximize resource utilization when configured
37. provides procedure support directly or via request / response tables and threads for external languages
38. allows for flexible node topologies for different decentralization variations and performance on physical data distributions
39. allows for virtual nodes and multi-tenancy to provide logical access for organizations on the same physical nodes

Target Use Cases and Dependencies

There are many dependencies, key ones include:

1. reuse or extension of existing database solutions ( SQL and NoSQL )
2. leverage open-source data lake and data mesh technologies
3. open-source solutions, tools and frameworks for data warehouses, aggregation, analytics services
4. use open-source security frameworks wherever feasible
5. Master Data Management synchronization ( centrally or distributed )
6. Software metadata management repositories ( central and distributed )
7. Secure remote privileged network access ( OpenSSH, Putty etc )
8. Secure network, storage, compute services
9. Kubernetes for virtual node management
10. Containerization where feasible to improve portability, platform independence

Key Use Cases in Scope

1. Big Data, high speed transaction life cycle management
2. Data suspension events for input data failing validations based on data policies
3. ACID transactions with definable commit boundaries
4. Shared Ledgers of Tamper resistant data across virtual data networks
5. Multiple, concurrent active - active data management services for nodes when use case fits
6. Data finalization events for shared ledger updates
7. Basic data work flows for multi-party review, signatures policies where needed
8. Multi-tenant support and architecture for multiple parties sharing nodes or clusters as virtual nodes with private ledger transactions 
9. Selective Data rollback, replay capabilities 
10. Data processing prioritization policies
11. Smart, dynamic log level management and event notification
12. Smart schema management for SQL and NoSQL data platforms ( SQL schema management depends on Liquibase ) 
13. Reduction of platform dependencies for client solutions and data implementation services where feasible
14. Remote data solution maintenance fix pack life cycle management
    1. validate target ready for change, apply fix pack, test changes, when tests fail - rollback changes, retest target for initial data states
15. Remote Automated test of data maintenance fix packs 
16. Ability to rollback, reapply data maintenance fix packs in sequence
17. Basic data mapping and transformation services using SQL or Object scripts or external routines
18. Data quality audit policies

Key Use Cases Out of Scope

1. limits on data quality management
2. limits on dynamic data access remediations based on policies
3. limits on finalization performance to optimize throughput
4. limits on capabilities based on dependent services
5. extensive data analytics
6. full data warehouse support
7. AI data quality tools
8. Quantum platform support

References

Key Concepts

Words matter in technology - they set expectations good and bad

replace 

blockchain

DLT

on-chain

off-chain 

digital twin

use instead

VSLT - virtual smart ledger technologies

shared ledger?  sharing happens multiple ways

shared current ledger

shared history ledger

shared data

shared current data

shared history data

private ledger

private data

backed digital asset 

transaction life cycle events - created, authorized, validated, processed, approved, committed, posted, finalized

ledger life cycle events - created, updated, offlined, onlined, current, outdated, archived, purged, used, unused, locked, unlocked, 

topology for SLT

• virtual DAO version 3 for operations, governance - ( like DTCC with trust, low collateral in efficient decentralized environment )
• virtual organization - VO - OO - Operational Organization
  • access to organization data, operations on smart contracts, transaction workflows, transaction approvals, accounts, wallets, virtual ledger
• virtual organization node - VON - MO - Manager Organization = OO + more
  • full node with all VO + node management, smart contract management, transaction endorsements, private ledger
• organization node - ON - NO - Node Organization = MO + more
• cluster - CL

Blockchains or Trust chains?

Almost all blockchain platforms have a performance issue on consensus methods and block ordering

Consider Trust data chains – trusted data chained for tamper-resistance as an alternative

Features of Trust data chains 

1. Write only ledgers
2. All Parties can access ledgers via API and data services easily
3. When required, parties can have read-only ledger access, write ledger access or both IF the governance model allows it
4. Every ledger transaction has a permanent id and a version id. 
5. Ledger transactions have a life cycle with commit and finalization different life cycle events
6. Ledger transactions can have linked off-ledger transactions paired ( my paycheck has amounts on ledger and a proxy id but no PII data ) by transaction and version ids
7. Ledger transaction data and off-ledger transaction data are each hashed and hashes recorded in the matched transaction hash table
8. Ledger transactions can be managed as a group using the transaction control table with a configurable mapping of transactions per control record

VSLN - Virtual Smart Ledger Networks

VSLN - each ledger type knows how to connect to the VSLN standard interface. VSLN can operate transaction protocols with optional capabilities to support many transaction use cases

VSLN key features - STS - smart trust services for trusts & decisions, privacy, multi-tenancy, virtual smart service layers, extensible component architecture, event-driven services, IAM for authentication & authorization services, pluggable services with interfaces and default service implementations, famous ABC parts

VSLN concepts

1. vnet - a logical subnet of a VSLN network that is a named scope that parties can join directly through a vnode or indirectly through a vprovider
2. vnode - a virtual node that implements a set of services for client roles.  The vnode provides a variety of services for the ledger network including:
3. multi-tenant capability
4. management of the network within a vnet
5. validators for actions, transactions on the vnet
6. replicas that receive copies of events, transactions, trusts, decisions, requests, responses, procedures
7. operators ( organizations, individuals with accounts ) operate and manage services in assigned roles on permissioned networks with access to assigned vnodes
8. parties ( organizations, individuals with accounts ) use services in assigned roles on permissioned networks with access to assigned vnodes
9. contracts - secured, digital, business contracts that are executed, signed, approved ( and notarized if required ), committed and finalized on VSLN
10. transaction consensus - POA and other methods as appropriate
11. client access to VSLN - rpc, api, vnode sdk

virtual smart ledger model - all parties create transactions on a virtual smart ledger network ( VSLN ) - made of multiple, dynamically coordinated ledgers

VSL supports different roles and optional vnode service types to fit use cases & organization needs

• Manager role and optional vnodes - manage and govern the VSL

  Manager nodes control and ( typically ) govern the operation of the VSL network
  There may be more than 1 manager node based on the requirements
  These nodes can also operate as shared nodes to host virtual nodes
   

• Validator role and optional vnodes - validate transactions on the VSL

  Validator nodes are defined by the use case  and the needs of an organizations that will operate them
  Validator nodes are involved in validating transactions of different types
  Validator node roles are assigned by manager nodes
  These nodes can also operate as shared nodes to host virtual nodes
  
  

• Replica role and optional vnodes - operate replicate nodes on the VSL

  Replica nodes are defined by the use case and the needs of an organizations that will operate them
  Replica nodes are receive replica updates of transactions of different types
  Replica node roles are assigned by manager nodes
  These nodes can also operate as shared nodes to host virtual nodes
  
  

• Virtual role and optional vnodes - provide virtual operations capabilities, identity, private transactions and data to organizations not directly hosting a node

  Virtual nodes are defined by the use case and the needs of an organizations that will operate them
  Virtual nodes are created for organizations to operate as private organizations on the VSL 
  Virtual nodes have their own organization identities, private transactions & private data and data access
  Virtual nodes can operate methods and smart contracts that assigned to them
  Virtual node roles are assigned by manager nodes

VSL global event management support - GEMS

Integrating the activities and results of operations on a VSL requires global event management support

Some DLT platforms provide basic, integrated GEMS ( eg Firefly Open-Source )

VSL services

Like many platform concepts, a VSL would support a variety of service types including REST apis and more

SGC - Smart Governed Contracts - VSL smart contracts - different than a blockchain smart contract

• Very different - goes beyond ERC3643 permissioned governed contracts for tokenized assets
• Adds more asset attributes:  owner, controller, processors, observers, 
• Adds more  states with events to transaction life cycle:  request > prepare > govern > approve > execute > commit > sign > finalize

VCE Solution Process for VSLN ( Virtual Smart Ledger Net )

see VCE > Value Chain Economies are virtual economic communities#VCE-ValueChainEconomiesareVirtualDigitalCommunities

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles