Updates to Home and Understanding FireFly sections

docs/_i18n/en.yml

@@ -10,8 +10,8 @@ pages:
   architecture: Architecture
   api_post_syntax: API Post Syntax
   api_query_syntax: API Query Syntax
-  blockchain_protocols: Blockchain protocols
-  broadcast_shared_data: Broadcast / shared data
+  blockchain_protocols: Blockchain Protocols
+  broadcast_shared_data: Broadcast / Shared Data
   broadcast_data: Broadcast data
   code_hierarchy: FireFly Code Hierarchy
   code_overview: FireFly Code Overview
@@ -21,7 +21,19 @@ pages:
   custom_smart_contracts: Work with custom smart contracts
   faqs: FAQs
   getting_started: Getting Started
-  private_data_exchange: Private data exchange
+  data_exchange: Data Exchange
   reference: Reference
   tutorials: Tutorials
-  understanding_firefly: Understanding FireFly
+  understanding_firefly: Understanding FireFly
+  chains: Connecting to other chains
+  remote_fabric_network: Remote Fabric Network
+  polygon_testnet: Polygon Testnet
+  arbitrum: Arbitrum Testnet
+  avalanche: Avalanche Testnet
+  binance_smart_chain: Binance Smartchain Testnet
+  near: NEAR Testnet
+  optimism: Optimism Testnet
+  multiparty_mode: Multiparty Mode
+  deterministic: Deterministic Compute
+  multiparty_flow: Multiparty Process Flow
+  firefly_core: Firefly Core

docs/_i18n/en/index.md

@@ -2,12 +2,17 @@
 
 ![Hyperledger FireFly](./images/hyperledger_firefly_social.png)
 
-Hyperledger FireFly is the first open source Supernode: a complete stack for enterprises to build and scale secure Web3 applications.
+Hyperledger FireFly is an open source Supernode, a complete stack for enterprises to build and scale secure Web3 applications. It is a project contributed by Kaleido and currently in the incubation phase for Hyperledger projects.
 
-The FireFly API for digital assets, data flows, and blockchain transactions makes it radically faster to build production-ready apps on popular chains and protocols.
+The easiest way to understand a FireFly Supernode is to think of it like a toolbox. Connect your existing apps and/or back office systems to the toolbox and within it there are two different sets of tools. One set of tools helps you connect to the Web3 world and the other set allows you to interact with multi-party systems. In FireFly language, these are referred to as [Web3 Gateway Mode](./overview/firefly_modes/gateway_mode.html) and [Multiparty Mode](./overview/firefly_modes/multiparty_mode.html).
+
+A FireFly Supernode simplifies the development process. Instead of building and maintaining the “plumbing’ or “middleware” yourself, a Supernode comes with pre-built solutions. These solutions include APIs, connector plugins, an orchestration layer, and user tools. Head to the Understanding FireFly section for more details.
 
 - [Understanding FireFly](./overview/)
+- [Getting Started](./gettingstarted/)
+- [Tutorials](./tutorials/)
 - [Reference](./reference/)
 - [Architecture](./architecture/)
 - [Contributors](./contributors/)
 - [API Spec](./swagger/swagger.html)
+- [FAQs](./faqs/)

docs/gettingstarted/firefly_cli.md

@@ -6,22 +6,18 @@ nav_order: 1
 ---
 
 # ① Install the FireFly CLI
+
 {: .no_toc }
 
 ## Table of contents
+
 {: .no_toc .text-delta }
 
 1. TOC
 {:toc}
 
 ---
 
-![FireFly CLI](../images/firefly_cli.png)
-
-## FireFly CLI
-
-The FireFly CLI can be used to create local FireFly stacks for offline development of blockchain apps. This allows developers to rapidly iterate on their idea without needing to set up a bunch of infrastructure before they can write the first line of code.
-
 ## Prerequisites
 
 In order to run the FireFly CLI, you will need a few things installed on your dev machine:
@@ -31,16 +27,19 @@ In order to run the FireFly CLI, you will need a few things installed on your de
 - openssl
 
 ### Linux Users
+
 > **NOTE**: For Linux users, it is recommended that you add your user to the `docker` group so that you do not have to run `ff` or `docker` as `root` or with `sudo`. For more information about Docker permissions on Linux, please see [Docker's documentation on the topic](https://docs.docker.com/engine/install/linux-postinstall/).
 
 ### Windows Users
+
  > **NOTE**: For Windows users, we recommend that you use [Windows Subsystem for Linux 2 (WSL2)](https://docs.microsoft.com/en-us/windows/wsl/). Binaries provided for Linux will work in this environment.
 
 ## Install the CLI
 
 There are several ways to install the FireFly CLI. The easiest way to get up and running with the FireFly CLI is to download a pre-compiled binary of the latest release.
 
 ### Download the package for your OS
+
 Go to the [latest release page](https://github.com/hyperledger/firefly-cli/releases/latest) and download the package for your OS and CPU architecture.
 
 ### Extract the binary and move it to `/usr/bin/local`
@@ -51,11 +50,11 @@ Assuming you downloaded the package from GitHub into your `Downloads` directory,
 sudo tar -zxf ~/Downloads/firefly-cli_*.tar.gz -C /usr/local/bin ff && rm ~/Downloads/firefly-cli_*.tar.gz
 ```
 
-If you downloaded the package from GitHub into a different directory, you will need to change the `tar` command above to wherever the `firefly-cli_*.tar.gz ` file is located.
+If you downloaded the package from GitHub into a different directory, you will need to change the `tar` command above to wherever the `firefly-cli_*.tar.gz` file is located.
 
 ### macOSUsers
- > **NOTE**: On recent versions of macOS, default security settings will prevent the FireFly CLI binary from running, because it was downloaded from the internet. You will need to [allow the FireFly CLI in System Preferences](https://github.com/hyperledger/firefly-cli/blob/main/docs/mac_help.md), before it will run.
 
+ > **NOTE**: On recent versions of macOS, default security settings will prevent the FireFly CLI binary from running, because it was downloaded from the internet. You will need to [allow the FireFly CLI in System Preferences](https://github.com/hyperledger/firefly-cli/blob/main/docs/mac_help.md), before it will run.
 
 ### Alternative installation method: Install via Go
 
@@ -68,6 +67,7 @@ go install github.com/hyperledger/firefly-cli/ff@latest
 ## Verify the installation
 
 After using either installation method above, you can verify that the CLI is successfully installed by running `ff version`. This should print the current version like this:
+
 ```
 {
   "Version": "v0.0.47",
@@ -76,6 +76,7 @@ After using either installation method above, you can verify that the CLI is suc
 ```
 
 ## Next steps: Start your environment
+
 Now that you've got the FireFly CLI set up on your machine, the next step is to create and start a FireFly stack.
 
-[② Start your environment →](setup_env.md){: .btn .btn-purple .float-right .mb-5}
+[② Start your environment →](setup_env.md){: .btn .btn-purple .float-right .mb-5}

docs/gettingstarted/sandbox.md

@@ -26,9 +26,9 @@ Now that you have a full network of three Supernodes running on your machine, le
 ## Video walkthrough
 
 <iframe width="736" height="414" src="https://www.youtube.com/embed/mmY7Vhwu-yk?start=2787" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-This video is a walkthrough of the FireFly Sandbox and FireFly Explorer from the FireFly 1.0 launch webinar. At this point you should be able to follow along and try all these same things on your own machine. 
+This video is a walkthrough of the FireFly Sandbox and FireFly Explorer from the FireFly 1.0 launch webinar. At this point you should be able to follow along and try all these same things on your own machine.
 
-## What is the FireFly Sandbox?
+<!-- ## What is the FireFly Sandbox?
 
 ![FireFly Sandbox](../images/sandbox/sandbox_broadcast.png)
 
@@ -40,7 +40,7 @@ The FireFly Sandbox sits logically outside the Supernode, and it acts like an "e
 
 The FireFly explorer is a part of FireFly Core itself. It is a view into the system that allows operators to monitor the current state of the system and investigate specific transactions, messages, and events. It is also a great way for developers to see the results of running their code against FireFly's API.
 
-![FireFly Explorer](../images/firefly_explorer.png)
+![FireFly Explorer](../images/firefly_explorer.png) -->
 
 ## Open the FireFly Sandbox for the first member
 

docs/index.md

@@ -4,4 +4,5 @@ title: pages.home
 nav_order: 1
 ---
 
-{% tf index.md %}
+{% tf index.md %}
+

docs/overview/firefly_modes/gateway/public_connector.md

@@ -0,0 +1,56 @@
+---
+layout: default
+title: Public Blockchain Connector Toolkit
+parent: Web3 Gateway Mode
+grand_parent: pages.understanding_firefly
+nav_order: 1
+---
+
+# Blockchain Connector Toolkit
+{: .no_toc }
+
+---
+
+## FireFly architecture for public chains
+
+One of the fastest evolving aspects of the Hyperledger FireFly ecosystem, is how it facilitates
+enterprises to participate in public blockchains.
+
+[![FireFly Public Transaction Architecture](../../../images/firefly_transaction_manager.jpg)](https://github.com/hyperledger/firefly-transaction-manager)
+
+The architecture is summarized as follows:
+
+- New **FireFly Transaction Manager** runtime
+  - Operates as a microservice extension of the FireFly Core
+  - Uses the `operation` resource within FireFly Core to store and update state
+  - Runs as a singleton and is responsible for `nonce` assignment
+  - Takes as much heavy lifting away from blockchain specific connectors as possible
+- Lightweight FireFly Connector API (`ffcapi`)
+  - Simple synchronous RPC operations that map to the most common operations supported across public blockchain technologies
+  - Examples:
+    - Find the next nonce for a given signing key
+    - Serialize a transaction from a set of JSON inputs and an interface definition
+    - Submit an un-signed transaction with a given gas price to the blockchain, via a signing wallet
+    - Establish a new block listener
+    - Poll for new blocks
+    - Establish a new event log listener
+    - Poll for new events
+- Pluggable **Policy Engine**
+  - Invoked to make decisions on transaction submission
+  - Responsible for gas price calculation
+  - Able to intervene and adjust the characteristics of signing/submission
+  - OSS reference implementation provided with Gas Station REST API integration
+- **Confirmation Manager**
+  - Extracted from the Ethconnect codebase
+  - Coupled to both transaction submission and event confirmation
+  - Embeds an efficient block cache
+- **Event Streams**
+  - Extracted from the Ethconnect codebase
+  - Checkpoint restart based reliable at-least-once delivery of events
+  - WebSockets interface upstream to FireFly Core
+
+This evolution involves a significant refactoring of components used for production solutions in the FireFly Ethconnect
+microservice since mid 2018. This was summarized in [firefly-ethconnect#149](https://github.com/hyperledger/firefly-ethconnect/issues/149),
+and cumulated in the creation of a new repository in 2022.
+
+You can follow the progress and contribute in this repo: https://github.com/hyperledger/firefly-transaction-manager

docs/overview/firefly_modes/gateway/public_private_chains.md

@@ -0,0 +1,66 @@
+---
+layout: default
+title: Public vs. Private chains
+parent: Web3 Gateway Mode
+grand_parent: pages.understanding_firefly
+nav_order: 1
+---
+
+# Public vs. Private Chains
+{: .no_toc }
+
+---
+
+## Public and Permissioned Blockchain
+
+A separate choice to the technology for your blockchain, is what combination
+of blockchain ecosystems you will integrate with.
+
+There are a huge variety of options, and increasingly you might find yourself
+integrating with multiple ecosystems in your solutions.
+
+A rough (and incomplete) high level classification of the blockchains available is as follows:
+
+- Layer 1 public blockchains
+  - This is where most token ecosystems are rooted and some of the popular ones include Ethereum, Avalanche, BNB Chain, etc.)
+- Layer 2 public scaling solutions backed by a Layer 1 blockchain
+  - These are increasing where transaction execution takes place that
+    needs to be reflected eventually back to a Layer 1 blockchain (due
+    to cost/congestion in the Layer 1 chains). An example of a Layer 2 solution would be Arbitrum which uses rollups to connect back to Ethereum.
+- Permissioned side-chains
+  - Historically this has been where the majority of production adoption of
+    enterprise blockchain has focussed, due to the predictable cost, performance,
+    and ability to manage the validator set and boundary API security
+    alongside a business network governance policy
+  - These might have their state check-pointed/rolled-up to a Layer 2 or Layer 1 chain
+
+The lines are blurring between these categorizations as the technologies and ecosystems evolve.
+
+## Public blockchain variations
+
+For the public Layer 1 and 2 solutions, there are too many subclassifications to go into in detail here:
+
+- Whether ecosystems supports custom smart contract execution (EVM based is most common, where contracts are supported)
+- What types of token standards are supported, or other chain specific embedded smart contracts
+- Whether the chain follows an unspent transaction output (UTXO) or Account model
+- How value is bridged in-to / out-of the ecosystem
+- How the validator set of the chain is established - most common is Proof of Stake (PoS)
+- How data availability is maintained - to check the working of the validators ensure the historical state is not lost
+- The consensus algorithm, and how it interacts with the consensus of other blockchains
+- How state in a Layer 2 is provable in a parent Layer 1 chain (rollup technologies etc.)
+
+## Common public considerations
+
+The thing most consistent across public blockchain technologies, is that the technical decisions are
+backed by token economics.
+
+Put simply, creating a system where it's more financially rewarding to behave honestly, than it
+is to subvert and cheat the system.
+
+This means that participation costs, and that the mechanisms needed to reliably get your transactions
+into these systems are complex. Also that the time it might take to get a transaction onto the chain
+can be much longer than for a permissioned blockchain, with the potential to have to make a number
+of adjustments/resubmissions.
+
+The choice of whether to run your own node, or use a managed API, to access these blockchain ecosystems
+is also a factor in the behavior of the transaction submission and event streaming.

docs/overview/firefly_modes/gateway_mode.md

@@ -0,0 +1,32 @@
+---
+layout: default
+title: Web3 Gateway Mode
+parent: pages.understanding_firefly
+nav_order: 3
+has_children: true
+---
+
+# Gateway Mode
+
+{: .no_toc }
+
+## Table of contents
+
+{: .no_toc .text-delta }
+
+1. TOC
+{:toc}
+
+---
+
+## Introduction
+
+Web3 Gateway Mode allows your FireFly Supernode to connect to any blockchain ecosystem, public or private. When a chain is connected, the FireFly Supernode may invoke custom smart contracts, interact with tokens, and monitor transactions. A single FireFly Supernode is able to have multiple namespaces, or isolated environments, where each namespace is a connection to a different chain.
+
+![Gateway Mode](../../images/gateway_mode.png "Gateway Mode")
+
+## Use Case Example
+
+There are many ways to use Gateway Mode. An example could be an interaction with a public chain such as Polygon.
+
+Imagine as a developer that there are multiple smart contracts that you have written for use on Polygon. You can start with FireFly's API generation to have a easy to use REST API interface to interact with the smart contracts. Next, imagine that one or more of your smart contracts conforms to the ERC-20 standard. Your Supernode is able to index the token operations (mint/burn/transfer/approvals) to see transaction history and balances associated with that contract. Finally, using FireFly’s tokens api, you may further interact with that ERC20.

docs/overview/blockchain_protocols.md → docs/overview/firefly_modes/multiparty/blockchain_protocols.md

@@ -1,19 +1,14 @@
 ---
 layout: i18n_page
 title: pages.blockchain_protocols
-parent: pages.understanding_firefly
-nav_order: 4
+parent: Multiparty Mode
+grand_parent: pages.understanding_firefly
+nav_order: 1
 ---
 
 # Blockchain protocols
 {: .no_toc }
 
-## Table of contents
-{: .no_toc .text-delta }
-
-1. TOC
-{:toc}
-
 ---
 
 ## Supporting multiple blockchain protocols
@@ -27,7 +22,7 @@ So you can choose the blockchain ecosystem that best meets the functional and
 non-functional requirements of your business network, and still benefit from the developer
 friendly APIs, event-driven programming model, and on-chain/off-chain coordination provided by FireFly.
 
-![FireFly Multiple Blockchain Protocols](../images/multi_protocol.png "FireFly Multiple Blockchain Protocols")
+![FireFly Multiple Blockchain Protocols](../../../images/multi_protocol.png "FireFly Multiple Blockchain Protocols")
 
 ## Core constructs and custom on-chain logic
 

docs/overview/broadcast.md → docs/overview/firefly_modes/multiparty/broadcast.md

@@ -1,19 +1,14 @@
 ---
-layout: i18n_page
-title: pages.broadcast_shared_data
-parent: pages.understanding_firefly
-nav_order: 8
+layout: default
+title: Broadcast shared data
+parent: Multiparty Mode
+grand_parent: pages.understanding_firefly
+nav_order: 2
 ---
 
 # Broadcast / shared data
 {: .no_toc }
 
-## Table of contents
-{: .no_toc .text-delta }
-
-1. TOC
-{:toc}
-
 ---
 
 ## Introduction
@@ -23,7 +18,7 @@ often that needs to include certain reference data that is available
 to all parties in the network. The data needs to be "broadcast" to all
 members, and also need to be available to new members that join the network
 
-![Multi-party Systems](../images/multiparty_system.png "Multi-Party System")
+![Multi-party Systems](../../../images/multiparty_system1.png "Multi-Party System")
 
 ## Blockchain backed broadcast