Key Points

References

...

Key Points

References

...

Microservices Application Pattern

Please see the example applications developed by Chris Richardson. These examples on Github illustrate various aspects of the microservice architecture.

Resulting Context

Benefits

...

• The coordinator is coupled with the services.
• If the coordinator goes down, it impacts the entire system.

Reactive Microservices based on event listeners

https://sites.google.com/a/mammatustech.com/mammatusmain/reactive-microservices

Benefits of Real OOP using Smalltalk before other languages improved

medium.com-The Forgotten History of OOP.pdf

...

RDD - Responsibility Driven Design - Wirfs-Brock

Why RDD?

more flexible than reactive services design

doesn't force everything to an API service model - just what should be an API vs a service vs a library vs a function

more natural way to find events produced and consumed by starting with business or client use cases

provides an easier way for business users to drive requirements specifications using natural language ( vs powerpoint logic )

Reactive Microservices based on event listeners

https://sites.google.com/a/mammatustech.com/mammatusmain/reactive-microservices

event maps, event storming in the context of microservices

effective really for software engineers but not so much for others

Benefits of Real OOP using Smalltalk before other languages improved

medium.com-The Forgotten History of OOP.pdf

https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f

...

P2P Escrow Transaction Pattern

goals

1. 2 parties complete an atomic swap of asset 1 for asset 2 without risk
2. contract config defines terms of the swap
3. if swap canif swap can't meet completion criteria, swap transaction is reversed for all parties returning initial states for each
4. optionally, a 3rd party notary service may need to approve the transaction
5. optionally, a 3rd party observer service may record the transaction
6. optionally, the 2 parties may be on different networks

...

specific validators only for that transaction type and parties are active

1. multi-party contract with roles where config defines terms of the swap
2. each party is identified and claims a role ( eg buyer, seller etc )
3. define multi-step transaction types
4. create transaction instance using the shared transaction manager with workflow from the contract config for that transaction type
5. each transaction has a unique ID
6. set the parties who validate the transaction on each ledger
7. contract takes control over both assets from each party using locks and confirms locks ( if funds or asset limited, policy may allow partial transactions )
   1. obligation set for each asset in the contract locking a portion of the assets for a time period
   2. after lock done, the lock status for all assets in the contract is shared
   3. if all assets in the contract locked, next step executes ( normally the trade )
   4. funds transferred to new party,  assets transferred to new party
   5. after delivery completed, obligations removed
8. after each step, the contract instance is updated for both parties and confirmed
9. signatures and consents required by all parties for each step
10. state changes are validated  as complete on each ledger for the current step before moving to next step - 100% endorsement of each update by relevant parties
11. if completion criteria for a step not fulfilled by X time, the transaction is cancelled and all parties are restored to initial states
12. completion messages recorded and events published on success or failure of the transaction

context

assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )

a blockchain with 2 parties as nodes each running a ledger copy and a contract

assume direct payment ( no margin loan ) on purchase transaction

blockchains implement escrow transaction interface services in a smart contract

...

step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transactionstep 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )all parties are notified of the completion of the escrow transaction

step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )

Hashed Timelock Contract  |  Hashed Timelock Agreement

https://www.investopedia.com/terms/h/hashed-timelock-contract.asp

https://academy.binance.com/en/glossary/hashed-timelock-contract

https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc

Hash Time Locked Contracts (HTLCs) Explained

https://medium.com/liquality/hash-time-locked-contracts-htlcs-explained-e88aa99cc824

Refund scenario for HTLC

 leverage HTLCs in Atomic Swaps, but also lead industry-wide efforts to standardize their implementation across different applications and blockchains.

Image Added

Bitcoin UXTO model

https://river.com/learn/bitcoins-utxo-model/

• Bitcoin does not have accounts with balances. Instead, individual coins are owned by Bitcoin users.
• An Unspent Transaction Output (UTXO) is a discrete piece of bitcoin. UTXOs are used as the inputs of every Bitcoin transaction.
• The UTXO model makes Bitcoin more auditable, transparent, and efficient than traditional financial systems, which rely on accounts, balances, and third parties.

Image Added

Potential Value Opportunities

...