docs(whitepaper): updates on architecture diagram and terminology #368
Conversation
Signed-off-by: Shingo Fujimoto <shingo_fujimoto@fujitsu.com>
| @@ -0,0 +1,1777 @@ | |||
| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
There was a problem hiding this comment.
@sfuji822 This looks like it has the same content as ./whitepaper/cactus_arch.svg, do we really need this or could it be deleted to avoid dupliation?
| - **Business Logic Plugin**: The entity executes business logic and provide integration services that are connected with multiple blockchains. The entity is composed by web application or smart contract on a blockchain. The entity is a single plugin and required for executing Hyperledger Cactus applications. | ||
| - **Command API Server (cmd-api-server)**: The server accepts a request from an End-user Application, and return a response depending on the status of the targeted trade. Trade ID will be assigned when a new trade is accepted. |
There was a problem hiding this comment.
The server accepts a request from an End-user Application, and return a response depending on the status of the targeted trade. Trade ID will be assigned when a new trade is accepted.
@sfuji822 Could it be that this description (quoted above) is better suited for a specific plugin than the entirety of the API server? And for the latter, potentially we could phrase it more generically with a focus on it being the host/shell/container/etc. for all the plugins?
There was a problem hiding this comment.
I did not intend to define generic API servers. I thought this should be named as "CACTUS node server" which provides API interfaces to both end-users and administrators.
| - **Business Logic Plugin**: The entity executes business logic and provide integration services that are connected with multiple blockchains. The entity is composed by web application or smart contract on a blockchain. The entity is a single plugin and required for executing Hyperledger Cactus applications. | ||
| - **Command API Server (cmd-api-server)**: The server accepts a request from an End-user Application, and return a response depending on the status of the targeted trade. Trade ID will be assigned when a new trade is accepted. | ||
| - **End-user Application**: The entity submits API calls to request a trade, which invokes a set of transactions on Ledger by the Business Logic Plugin. |
There was a problem hiding this comment.
The entity submits API calls to request a trade, which invokes a set of transactions on Ledger by the Business Logic Plugin.
@sfuji822 Would it make sense to mention something more generic than requesting a trade? For example the end user application could submit an API call to request information (e.g. querying ledger state without modifying it).
There was a problem hiding this comment.
My intention was Trade is changing Ledger behind LedgerPlugin, but queries will not change the state of Ledger.
Do you want to have the capability to make a query through BLP? > @petermetz
There was a problem hiding this comment.
My intention was Trade is changing Ledger behind LedgerPlugin, but queries will not change the state of Ledger.
@sfuji822 Makes sense. Do you feel that the word trade can really encompasses all of our non-financial use cases? As-in, would you describe an end user application uploading cat pictures to a ledger as a trade?
Do you want to have the capability to make a query through BLP? > @petermetz
@sfuji822 I have no strong opinions on that. Should be up to the author of the BLP IMO.
| - **Verifier**: The entity accepts only sucussfully verified operation results by verifying the digital signature of the validator. Note that "Validator" is apart from "Verifier" over a bi-directional channel. | ||
| - **Cactus Routing Interface**: The entity is a routing service between "Business Logic Plugin" and "Ledger Plugin(s)". The entity is also a routing service between Business Logic Plugin and API calls from "Application user(s)". | ||
| - **Ledger-n**: DLT platforms(e.g. Ethereum, Quorum, Hyperledger Fabric, ...) | ||
| - **Validator Server**: The server accepts a connection from Verifier, and it provides Validator API, which can be used for controlling and monitoring Ledger behind it. The LedgerConnector will be implemented for interacting with the Ledger nodes. |
There was a problem hiding this comment.
Validator API, which can be used for controlling and monitoring Ledger behind it
@sfuji822 Just want to converge on the mental models: What does the controlling here refer to? When I read validator, I imagined it would mostly just read ledger state and make statements about that rather than actually being in control of the ledger itself.
There was a problem hiding this comment.
Discussed at maintainer's call 2020-12-08, controlling as in submitting transactions, not as in owning the entire ledger.
@petermetz
There was a problem hiding this comment.
I meant controlling is issuing transaction regarding the user's account or assets.
I will change the wording with "issuing signed transactions".
Could you accept this change? @petermetz
There was a problem hiding this comment.
I meant controlling is issuing transaction regarding the user's account or assets.
I will change the wording with "issuing signed transactions".
Could you accept this change? @petermetz
@sfuji822 Yes, sounds good, thank you!
| - **Ledger-n**: DLT platforms(e.g. Ethereum, Quorum, Hyperledger Fabric, ...) | ||
| - **Validator Server**: The server accepts a connection from Verifier, and it provides Validator API, which can be used for controlling and monitoring Ledger behind it. The LedgerConnector will be implemented for interacting with the Ledger nodes. | ||
| - **Verifier**: The entity accepts only sucussfully verified operation results by verifying the digital signature of the validator. Verifier will be instantiated by calling the VerifierFactory#create method with associated with the Validator to connect. Each Verifier may be temporarily enabled or disabled. Note that "Validator" is apart from "Verifier" over a bi-directional channel. | ||
| - **Verifier Registroy**: The information about active Verifier. The VerifierFactory uses this information to instantiate Verifier for the Business Logic Plugin. |
There was a problem hiding this comment.
Verifier Registroy
Typo? https://en.wikipedia.org/wiki/Registry
The information about active Verifier.
Is it implied there that there's only one verifier active or could it be multiple active verifiers simultaneously ?
There was a problem hiding this comment.
I will fix the typo 'Registry'.
Is it implied there that there's only one verifier active or could it be multiple active verifiers simultaneously ?
I thought that, but we may clarify if Verifier(s) to be multiple instances or not.
Our prototyped code have instanced interface to Validator once it was created by ValidatorFactory.
I would like to hear your opinion about this. > @petermetz
There was a problem hiding this comment.
I thought that,
@sfuji822 Sorry, wasn't sure which one of the two you meant by that. Do you mean a) there's only one verifier active or b) could it be multiple active verifiers simultaneously
| @@ -0,0 +1,1777 @@ | |||
| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
There was a problem hiding this comment.
I added a boundary around the validators wrapping them with the API server blue box as well and added a legend entry for the same thing. This is is roughly what I was talking about during our last call.
There was a problem hiding this comment.
Humm. That is something different from my understanding.
The icon in the Validator was Ledger, which may consist of multiple nodes that participated in the blockchain network.
However, Validator (API) Server will be the point of contact for the Ledger, and it will be an independent server from other Validators.
This is because Validator is a client or node of Ledger which is operated by the BLP of CACTUS.
There was a problem hiding this comment.
Humm. That is something different from my understanding.
The icon in the Validator was Ledger, which may consist of multiple nodes that participated in the blockchain network.
However, Validator (API) Server will be the point of contact for the Ledger, and it will be an independent server from other Validators.
This is because Validator is a client or node of Ledger which is operated by the BLP of CACTUS.
@sfuji822 Gotcha, I'll take a step back/zoom out a bit in that case: The validator. => Is the logic of the validator implemented as a plugin or is the logic prescribed/hardcoded?
…elay/bumpalo-3.12.0 Bump bumpalo from 3.10.0 to 3.12.0 in /core/relay
This PR resolves the issue regarding out-of-date documentations.
Signed-off-by: Shingo Fujimoto shingo_fujimoto@fujitsu.com