Key Points

1. Grid uses Sawtooth and is developed in Rust

References

Key Concepts

Blockchain Interoperability

interoperability use cases

simple Oracles - read only

simple asset exchanges

Dynamic relations between parties

discovery services, routers, decentralized directory services, lookups, authentication services

permanent or temporary relations

Full ACID transactions with rollback across different types of blockchains with privacy

the escrow, asynchronous, tokenized ACID transaction with rollabck

Play forward transactions from a checkpoint for a blockchain member

Hyperledger Cacti - DLT Interoperatiblity Services

Hyperledger Weaver - merged into Cacti in 2022

https://www.hyperledger.org/blog/2021/06/09/meet-weaver-one-the-new-hyperledger-labs-projects-taking-on-cross-chain-and-off-chain-operations

Key principles that guide Weaver’s design are:

• Accommodate DLT heterogeneity without favoring a particular DLT design
• Allow networks to maintain their independence and collective sovereignty
• Minimize coupling during cross-network interactions
• Rely on common standards for cross-network protocol units
• Do not require a trusted intermediary or third-party ledger
• Do not require changes to existing DLT stacks
• Make no security and trust assumptions on Weaver components
• Treat privacy and least privilege as a first-class requirement

Weaver addresses three broad classes of use cases:

1. Data transfer: ledger data (state) communication with proof
2. Asset transfer: movement of an asset from one ledger to another
3. Asset exchange: atomic exchange of asset ownership in different ledgers

The protocols to realize these use cases can be abstracted into a common stack of layers akin to the OSI model, from message formats at the bottom to governance rules at the top (see diagram below).

Hyperledger Labs Blockchain Interoperability Project

https://github.com/hyperledger-labs/blockchain-integration-framework

• Whitepaper
• Original Design Principles Google Doc

If you look at the Blockchain Interoperability space, several different approaches have been proposed. Among the existing contributions, we identified two main ways to solve the interoperability problem. The “connector approach” focuses on building transfer protocols for non-trusted blockchain gateways (e.g. Interledger). The “blockchain of blockchains approach” proposes a central blockchain “hub” to connect multiple blockchain “zones” together (e.g. Cosmos).

This lab project proposes an alternative to these models, and it is designed specifically for permissioned blockchain networks, but later expanded to permissionless ones as well.

How It Works

Blockchain Integration Framework introduces an “interoperability validator” overlay network for each of the interoperable blockchains. Interoperability validators are known or broadly discoverable by the ecosystem and are typically participants already taking part in the governance or consensus. Interoperability validators will collectively handle export requests from local nodes by verifying against their version of the ledger (steps 1 to 3). Each request is answered by a (configurable) minimum quorum of validator signatures necessary or rejected as fast as possible (steps 4 and 5). The network can continue working even if some of the validators are down, or not participating, but assuming the minimum quorum can be guaranteed. Messages certified by a distributed ledger’s transfer validators can be delivered by any secure off-chain communication system (step 6). A proof coming from a foreign distributed ledger can be verified against the public keys of the transfer validators of that foreign distributed ledger either locally by the recipient or using an on-chain logic –- typically smart-contracts (step 7 and 8)

SATP - Secure Asset Transfer (SAT) Protocol -  like DRDA for DLT

https://datatracker.ietf.org/doc/draft-ietf-satp-core/

SAT is a protocol operating between two gateways
   that conducts the transfer of a digital asset from one gateway to
   another, each representing their corresponding digital asset
   networks.  The protocol establishes a secure channel between the
   endpoints and implements a 2-phase commit (2PC) to ensure the
   properties of transfer atomicity, consistency, isolation and
   durability.

For DLT, this architecture makes sense as ledger independent model for transfers 

In concept, this is the same model DRDA implements for Distributed Database Transactions are 2 way commits for ACID transactions

In SATP’s scope today:

● Unidirectional asset transfer

● Gateway-to-gateway asset transactions

Out of scope today – future scopes TBD

● Multi-directional asset “swaps”

● Additional related digital objects ○ e.g. transmission of a Bill of Lading

● In-network protocols for transfer/locking before SATP

<< Project Lithium Handled Escrow Exchanges

 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Secure Asset Transfer Protocol . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SAT Model . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Stages of the Protocol . . . . . . . . . . . . . . . . . 6
4.4. Gateway Cryptographic Keys . . . . . . . . . . . . . . . 7
5. SATP Message Format, identifiers and Descriptors . . . . . . 7
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. SATP Message Format and Payloads . . . . . . . . . . . . 8
5.2.1. Protocol version . . . . . . . . . . . . . . . . . . 8
5.2.2. Message Type . . . . . . . . . . . . . . . . . . . . 8
5.2.3. Digital Asset Identifier . . . . . . . . . . . . . . 9
5.2.4. Transfer-Context ID: . . . . . . . . . . . . . . . . 9
5.2.5. Session ID: . . . . . . . . . . . . . . . . . . . . . 10
5.2.6. Gateway Credential Type . . . . . . . . . . . . . . . 10
5.2.7. Gateway Credential . . . . . . . . . . . . . . . . . 10
5.2.8. Payload Hash . . . . . . . . . . . . . . . . . . . . 10
5.2.9. Signature Algorithms Supported . . . . . . . . . . . 10
5.2.10. Message Signature . . . . . . . . . . . . . . . . . . 10
5.2.11. Lock assertion Claim and Format . . . . . . . . . . . 10
5.3. Negotiation of Security Protocols and Parameters . . . . 10
5.3.1. TLS Secure Channel Establishment . . . . . . . . . . 11
5.3.2. Client offers supported credential schemes . . . . . 11
5.3.3. Server selects supported credential scheme . . . . . 11
5.3.4. Client asserts or proves identity . . . . . . . . . . 11
5.3.5. Messages can now be exchanged . . . . . . . . . . . . 11
5.4. Asset Profile Identification . . . . . . . . . . . . . . 11
6. Overview of Message Flows . . . . . . . . . . . . . . . . . . 12
7. Identity and Asset Verification Stage (Stage 0) . . . . . . . 13
8. Transfer Initiation Stage (Stage 1) . . . . . . . . . . . . . 13
8.1. Transfer Initialization Claim . . . . . . . . . . . . . . 14
8.2. Conveyance of Gateway and Network Capabilities . . . . . 16
8.3. Transfer Proposal Message . . . . . . . . . . . . . . . . 17
8.4. Transfer Proposal Receipt Message . . . . . . . . . . . . 18
8.5. Reject Message . . . . . . . . . . . . . . . . . . . . . 19
8.6. Transfer Commence Message . . . . . . . . . . . . . . . . 20
8.7. Commence Response Message (ACK-Commence) . . . . . . . . 21
9. Lock Assertion Stage (Stage 2) . . . . . . . . . . . . . . . 22
9.1. Lock Assertion Message . . . . . . . . . . . . . . . . . 23
9.2. Lock Assertion Receipt Message . . . . . . . . . . . . . 24
10. Commitment Preparation and Finalization (Stage 3) . . . . . . 25
10.1. Commit Preparation Message (Commit-Prepare) . . . . . . 25
10.2. Commit Ready Message (Commit-Ready) . . . . . . . . . . 26
10.3. Commit Final Assertion Message (Commit-Final) . . . . . 27
10.4. Commit-Final Acknowledgement Receipt Message
(ACK-Final-Receipt) . . . . . . . . . . . . . . . . . . 28
10.5. Transfer Complete Message . . . . . . . . . . . . . . . 29
11. SATP Session Resumption . . . . . . . . . . . . . . . . . . . 30
11.1. Primary-Backup Session Resumption . . . . . . . . . . . 31
11.2. Recovery Messages . . . . . . . . . . . . . . . . . . . 31
12. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 32
12.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 33
13. Security Consideration . . . . . . . . . . . . . . . . . . . 33
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 34
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
16. Appendix: Error Types . . . . . . . . . . . . . . . . . . . . 34
16.1. Transfer Commence and Response errors . . . . . . . . . 34
16.2. Lock Assertion errors . . . . . . . . . . . . . . . . . 34
16.3. Lock Assertion Receipt errors . . . . . . . . . . . . . 35
16.4. Commit Preparation errors . . . . . . . . . . . . . . . 35
16.5. Commit Preparation Acknowledgement errors . . . . . . . 35
16.6. Commit Ready errors . . . . . . . . . . . . . . . . . . 35
16.7. Commit Final Assertion errors . . . . . . . . . . . . . 36
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . 36

SATP Overview session - 2024

1. Secure File Transfer Protocol (SFTP) Not to be confused with Simple File Transfer Protocol or Secure file Transfer Protocol. Roshnee Ravikumar Suneetha Tedla

2. Outline • Background • Why SFTP? • What is it? • When we use it? • SFTP implementation and Application • Pitfalls and challenges • Future work

3. Background Why SFTP? We are shutting off clear-text FTP access because when you log in with your username and password, people snooping on the network can capture all information sent. What is SFTP? SSH File Transfer Protocol (also Secret File Transfer Protocol,SecureFTP, or SFTP) is a network protocolthat provides file access, file transfer, and file management functionalities over any reliable data stream. (SSH) version 2.0 to provide secure file transfer capability When we use it? Big files, Regulatory transactions, Audits, Sensitive information

4. SFTP Benefits • Encrypted username/passwords • Encrypted data transfers • Prevent users from reading other users ftp data • Prevent full command line access from outside users • Prevent full command line access from any internet facing connection • Allow full command line access to System admin from internal network opening ‘ssh’ on port 2222

5. Implementation and Applications • Implementations to understand secure data transfer ( protocols, software) • openssh-server, /usr/local/etc/sshd_config • Uses SSH-2 • wxWidgets: 2.8.11 • GnuTLS: 2.10.2 • Key Authorizations • Certificates

6. Applications • Filezilla (Open Source) (uses as client) • WS-FTP Pro (client) • Open-ssh (Software) • WinSCP ( Windows Client) • FLASHFXP ( Software) • SEEBURGER( cloud computing) • Cyberduck (Cloud computing)

7. Highest-level results • Benefits are Secret sharingfiles and security, integrity, faster then traditional posting • Tradeoffs are necessary like performance and Exchanging keys or passwords

8. Pitfalls and Challenges • security vulnerability in applications and software • The Administrator user, password and software management and has to send an password to the users through an email and this is not good method • Port forwarding and TLS • Data Volume ( Reliable Networks???) • If the users does not clean up the old data and the files may be filled up the disk and admin has to come up with cron jobs to clean. • Data Accumalation.

9. Discoveries and Future work • Two formidable challenges to privacy: • Data need to transfer forever and how can we make it secure all the time. • Human mistakes ( giving wrong permissions to wrong people) • Disclosures of data and keys have become commonplace • Some of the applications came online to provide secure transfer and they suffer from data leakage. • (SEEBURGER Managed File Transfer Wins Award for Data Leakage Protection) beyond SFTP. • Textastic 2.1 for iPad adds SFTP support and more FTP options Make easy use of sftp for wireless

SATP document folder online

Potential Value Opportunities

Potential Challenges

Performance

Candidate Solutions

Hyperledger Cacti Lab 2022

https://wiki.hyperledger.org/display/events/Blockchain+Interoperability+with+Hyperledger+Cacti

Blockchain Interoperability with Hyperledger Cacti Workshop

Time:

• Monday November 14, 2022 from 11am - 2pm ET

Registration:

Registration for the event is free.  If you're interested in attending, we ask that you sign up now since space is limited.

• Registration for the Cacti Workshop

Workshop description:

We present the "Blockchain Interoperability with Hyperledger Cacti" workshop, the first Hyperledger Foundation Community Workshop dedicated to blockchain interoperability. This is a three hour online course to introduce the core concepts and principles of blockchain interoperability. You will learn the foundations of interoperability, followed by an introduction to several Hyperledger projects on the field: Weaver, YUI, Firefly, and Cacti. We present in depth several Cacti's components, including its Plugin Architecture, API Server, Test Development & Execution (All-In-One Container Images), an Hello World of Cacti, and considerations about the future of the project.

Preparation :

1) Install the project dependencies and development environment described at the developer's guide (until the command yarn run configure).

2) Run a test from any package to confirm that everything is correctly setup. Follow the instructions from the developer's guide from the yarn run configure step up to the build-script-decision tree step (excluding).

This workshop only supports Ubuntu 20.04 LTS VM (or bare metal).

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles