Skip to content

Commit

Permalink
docs(weaver): fixed formatting, updated maintainers info, and added i…
Browse files Browse the repository at this point in the history 
…mage

Updated Discord handles in MAINTAINERS.md.
Added a Cactus legacy architecture diagram for reference.
Fixed formatting in old Weaver docs bullet lists.

Signed-off-by: VRamakrishna <[email protected]>
  • Loading branch information
@VRamakrishna @petermetz
VRamakrishna authored and petermetz committed Oct 4, 2023
1 parent 98b8af2 commit e45bab4
Show file tree
Hide file tree
Showing 5 changed files with 17 additions and 17 deletions.
14 changes: 7 additions & 7 deletions MAINTAINERS.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,17 +6,17 @@ Maintainers
| Name | GitHub | Chat |
|------|--------|------|
| Jonathan Hamilton | [jonathan-m-hamilton][jonathan-m-hamilton] | JHamilton |
| Izuru Sato | [izuru0][izuru0] | Izuru Sato#6434 |
| Peter Somogyvari | [petermetz][petermetz] | peter_somogyvari#3365 |
| Takuma TAKEUCHI | [takeutak][takeutak] | takeutak#7220 |
| Izuru Sato | [izuru0][izuru0] | izurusato |
| Peter Somogyvari | [petermetz][petermetz] | peter_somogyvari |
| Takuma TAKEUCHI | [takeutak][takeutak] | takeutak |
| Jagpreet Singh Sasan | [jagpreetsinghsasan][jagpreetsinghsasan] | jagpreetsinghsasan |
| Venkatraman Ramakrishna | [VRamakrishna][VRamakrishna] | Ramakrishna#6645 |
| Sandeep Nishad | [sandeepnRES][sandeepnRES] | sandeepn#1092 |
| Venkatraman Ramakrishna | [VRamakrishna][VRamakrishna] | vramaiitkgp |
| Sandeep Nishad | [sandeepnRES][sandeepnRES] | sandeepn |

[jonathan-m-hamilton]: https://github.com/jonathan-m-hamilton
[izuru0]: https://github.com/izuru0
[petermetz]: https://github.com/petermetz
[takeutak]: https://github.com/takeutak
[jagpreetsinghsasan]: https://github.com/jagpreetsinghsasan
[VRamakrishna]: https://github.com/VRamakrishna/
[sandeepnRES]: https://github.com/sandeepnRES
[VRamakrishna]: https://github.com/VRamakrishna
[sandeepnRES]: https://github.com/sandeepnRES
Binary file added images/cactus-architecture.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion weaver/docs/docs/external/architecture-and-design/drivers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,6 @@ title: Drivers
The driver is responsible for all communication between the relay and its network. In the previous sections we have thought about the driver as a component of the relay. We have done this because conceptually it makes sense to think about it like that. However, in our reference implementation we have made it a seperate process which communicates with the relay via gRPC, as shown below. There are two main reasons for this:

1. There must exist a different driver for each network type (e.g. Fabric, Corda etc.) and therefore having the driver as a seperate process makes it easy to "plug" different drivers into the relay.
1. A possible use case of the relay is that a single relay instance may have multiple drivers (e.g. if multiple entities in the network want to run their own driver). In this case, this plugin style approach of drivers makes it possible to do without having to modify code for each configuration.
2. A possible use case of the relay is that a single relay instance may have multiple drivers (e.g. if multiple entities in the network want to run their own driver). In this case, this plugin style approach of drivers makes it possible to do without having to modify code for each configuration.

![](/architecture-assets/driver_architecture.png)
10 changes: 5 additions & 5 deletions weaver/docs/docs/external/architecture-and-design/relay.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,8 @@ The diagram below shows an example communication between two networks, A and B,
![](/architecture-assets/relay_flow.png)

1. An application sends a request to their networks relay over gRPC
1. The local relay inspects the query within the request and uses the relevant information to forward the request to the correct remote relay
1. The remote relay's driver interprets the query and invokes the smart contract for the query
1. Once network B has returned a response to its relay, the relay forwards the response back to relay A
1. The application gets the response from the relay, this can either be via a push or pull mechanism
1. The application invokes a domain specific smart contract to process the response from network B
2. The local relay inspects the query within the request and uses the relevant information to forward the request to the correct remote relay
3. The remote relay's driver interprets the query and invokes the smart contract for the query
4. Once network B has returned a response to its relay, the relay forwards the response back to relay A
5. The application gets the response from the relay, this can either be via a push or pull mechanism
6. The application invokes a domain specific smart contract to process the response from network B
8 changes: 4 additions & 4 deletions weaver/docs/docs/external/user-stories/financial-markets.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,9 @@ This protocol essentially has three phases:

The process proceeds as follows, and is further illustrated in the figure below:
1. **Org-A locks its securities in FSN ledger**: *Org-A* first creates some secret S, known only to it and locks its securities using the hash of S. The securities are configured to redeemable by *Org-B* if it presents S within some specified time threshold.
1. **Org-B locks payments tokens in CBDC ledger**: Org-B, observes that *Org-A* has locked its securities in the FSN network and does a corresponding lock of its payment tokens with the hash of S, used by *Org-A* in locking its securities. The payment tokens are redeemable only by Org-A, if it submits a transaction that reveals S within a specified time.
1. **Org-A checks Org-B's contract in CBDC ledger**: *Org-A* checks the CBDC network to ensure that the payments tokens are locked by Org-B.
1. **Org-A claims payments in CBDC ledger**: *Org-A* submits a transaction to claim the payments tokens, by revealing the secret S.
1. **Org-B claims securities in FSN ledger**: *Org-B* observes that the value of S has been revealed in the CBDC network by *Org-A* in step 4, and submits a transaction to claim the securities in the FSN network using the revealed secret.
2. **Org-B locks payments tokens in CBDC ledger**: Org-B, observes that *Org-A* has locked its securities in the FSN network and does a corresponding lock of its payment tokens with the hash of S, used by *Org-A* in locking its securities. The payment tokens are redeemable only by Org-A, if it submits a transaction that reveals S within a specified time.
3. **Org-A checks Org-B's contract in CBDC ledger**: *Org-A* checks the CBDC network to ensure that the payments tokens are locked by Org-B.
4. **Org-A claims payments in CBDC ledger**: *Org-A* submits a transaction to claim the payments tokens, by revealing the secret S.
5. **Org-B claims securities in FSN ledger**: *Org-B* observes that the value of S has been revealed in the CBDC network by *Org-A* in step 4, and submits a transaction to claim the securities in the FSN network using the revealed secret.

![Simple DvP scenario in financial markets](../../../static/use-cases/financial-markets-2.png)

0 comments on commit e45bab4

Please sign in to comment.