Topics

[External] [Hyperledger Cactus] Regarding the Whitepaper / Besu Connector - Rafael Belchior


Somogyvari, Peter
 

Hi Rafael,


Answering the besu specific questions below, hopefully others can weigh in as well (and also on the other questions).

-If I understood correctly, a BesuTestLedger is a Besu node connected to a network (hold by itself). Can we connect two different Besu nodes on the same private net? I will need to do so for the blockchain migration feature.
Not with the current docker image, unfortunately. The "besu-all-in-one" image was specifically designed to be as simple as possible for faster/less error prone test execution.
Now with that said, I'm 100% open to extending it with multi-node support in a way that still keeps the number of containers at 1 (multiple containers is always more complexity).
The way I imagine it happening is that we have a single container that runs multiple besu processes that listen on different ports and are isolated on the file system via different directories as well.
It would need some tweaking, but it should definitely be doable unless Besu itself depends on it being a singleton in the sense that if you try to launch a second process it will knock the other one out. Software that does the latter is rare but I've seen it happen. For example Microsoft's HyperV grabs the CPU's nested virtualization capabilities for itself at boot time which then makes it impossible to run VirtualBox and HyperV on the same Windows installation. Besu is probably not doing anything like this so it should be just a matter of time/effort to get it done.
You might want to drop a note on this issue where coincidentally we started talking about the same thing:


-Besu exposes an API that can be used to interact with Ethereum blockchains. How can we access it? Do we have to change BesuTestLedger to call a specific command from the docker container peter/besu-all-in-one?
If you mean the RPC API, then it's already exposed through a port that you can use (and also customize through the constructor parameters).
But if you mean some API custom to Besu and not the standard GETH API, then I have to confess I don't know much about that, BUT if I'm pretty sure it's just a matter of exposing that API on yet another TCP port and then it's usable. So either it's already exposed like that and I'm just not aware of it, or it can be exposed with minimal effort.

I have to note here that recently we discovered a macOS specific issue with TCP/IP routing for container's and this means that we'll have to slightly refactor all the *TestLedger classes to bind to port zero on the host (e.g. localhost). Then all the *TestLedger classes will have methods to retrieve the randomized port that gets allocated through binding to port 0.
This is not something I even started working on yet but is definitely going to happen at some point because the tests are failing on macOS as we speak...


-Is the default network a private network? Can we parametrize Besu's all in one container to initialize the Besu node in another network (let's say, Ropsten or the Ethereum mainnet)?

Most or all of these things are hardcoded at the moment, but if features like this are needed I definitely want to work on these as well. Also, if you need something specific feel free to add it as a feature so long it doesn't make things overly complicated. What do I mean by complicated: If you add a new constructor parameter or two and those are then fed to the container creation process, then it's fine, but if you add a bunch of parameters and even the basic logic of the class itself has to be changed and let's say the number of lines has tripled, then that seems complicated (without context).

Also a good idea to open issues for these to keep track of what's missing.

-Regarding the Besu's connectors interfaces: I'm not sure what EEAClient is for - is it a wrapper for the Web3 client, which is on the "eea" attributed? Why do we need the interfaces IWeb3InstanceExtended, IEeaWeb3Extension, and IWeb3Instance?

EEA => Enterprise Ethereum Alliance: https://entethalliance.org/

The EEAClient is an extension to Web3 that is developed by the same people who are developing Besu. The extension is necessary so that you can use the non-Ethereum features of Besu such as private transactions (if you look at the Besu getting started docs focusing on NodeJS you'll see them using the EEAClient there, that's how I got to it).

- In the blockchain migration feature I am developing, I'll need to record information from a deployed smart contract. For example, I would need to store the list of transactions that are related to such contract; the creator's address, balance, etc... I will create an interface to hold that info.
Does it makes sense that such interface belongs to the blockchain migrator feature, or would it be more reasonable to include it in the Besu connector code?
This is one of those things where I have a gut feeling that it's probably better to have it in the migration feature rather than the connector, but it might turn out to be entirely wrong.
So, for now I'm saying it's better in the migration feature, but don't be surprised if later I reverse course after seeing the actual code. 🙂

-What would be your bet for the short term consortium management? To trust an instance of a Cactus deployment that collects the decisions from other Cactus deployments? We can trivially decentralize the solution by allowing instances to vote, and following a majority vote, but if there are malicious nodes we have a problem.

Note: I'm just dispersing my personal ideas here, all of this is subject to change because we haven't finalized it yet (still).
The only thing I would trust is the single, signed/certified JSON document containing the metadata of the consortium. Such a document would be created at the time of the bootstrapping of the consortium by it's founding members (how to update it is of course the tough question and to be defined exactly).
In the consortium description, each member's node(s) are listed in a JSON array with properties describing the node's DNS host, the node's public key and the list of plugins the node has loaded in it (the fact that each member node can have different plugins loaded is a complication I just recently became aware of).
The consortium description document would be publicly available for download to anybody on the main web domain of the consortium (I already bought a domain for our own public test deployment for this purpose). This also implies that when you visit a URL of the consortium and download this document, you choose to trust the consortium and all of it's nodes/members and you are protected from fake/malicious nodes assuming that the consortium members themselves are not malicious.

Example pseudo code (again, just making this up, not approved by maintainers yet):
{
"name": "MyCoolConsortium",
"x509-certificate": "some-signed-certificate-chain-containing-signatures-of-all-bootstrapping-members-of-the-consortium-this-could-also-be-something-other-than-x509-maybe-threshold-crypto-stuff",
"nodes": [
{
    "host": "cactus.member-a.com",
    "publicKey": "...",
    "plugins": ["plugin-id-1", "plugin-id-2", ...]
},
{
    "host": "cactus.member-b.com",
    "publicKey": "...",
    "plugins": ["plugin-id-3", "plugin-id-2", ...]
}

]
}


Peter

Peter Somogyvari

Technology Architect

Accenture Products & Platforms (APP)

Office: +1 (415) 537-5541

Mobile: +1 (650) 488-1741



From: cactus@... <cactus@...> on behalf of Rafael André Pestana Belchior <rafael.belchior@...>
Sent: Wednesday, June 17, 2020 1:05 PM
To: cactus@... <cactus@...>
Subject: [External] [Hyperledger Cactus] Regarding the Whitepaper / Besu Connector - Rafael Belchior
 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

Hello all,
Hope this e-mail finds you well and safe!

I have some questions on the Besu Connector that I would like to clarify. But before, as a quick note, I would like to share some recent work with you, a survey on blockchain interoperability solutions up to May 2020.  There is also an article that summarizes the 58-page survey into a 4-minute read article.
 
There is a lot of information there, and I think we can leverage this work to improve the whitepaper, for example:

1: the related work section
2: creating a glossary with blockchain interoperability definitions (section 2.3 of the survey)
3: discussion about existing blockchain interoperability standards (section 6.2) 
4: discussion on challenges of blockchain interoperability (section 6.5)
 
If you think that's useful, I can further contribute to the whitepaper.
 
Regarding Besu:
-If I understood correctly, a BesuTestLedger is a Besu node connected to a network (hold by itself). Can we connect two different Besu nodes on the same private net? I will need to do so for the blockchain migration feature.

-Besu exposes an API that can be used to interact with Ethereum blockchains. How can we access it? Do we have to change BesuTestLedger to call a specific command from the docker container peter/besu-all-in-one?
-Is the default network a private network? Can we parametrize Besu's all in one container to initialize the Besu node in another network (let's say, Ropsten or the Ethereum mainnet)?

-Regarding the Besu's connectors interfaces: I'm not sure what EEAClient is for - is it a wrapper for the Web3 client, which is on the "eea" attributed? Why do we need the interfaces IWeb3InstanceExtended, IEeaWeb3Extension, and IWeb3Instance?

-In the blockchain migration feature I am developing, I'll need to record information from a deployed smart contract. For example, I would need to store the list of transactions that are related to such contract; the creator's address, balance, etc... I will create an interface to hold that info.
Does it makes sense that such interface belongs to the blockchain migrator feature, or would it be more reasonable to include it in the Besu connector code?

-What would be your bet for the short term consortium management? To trust an instance of a Cactus deployment that collects the decisions from other Cactus deployments? We can trivially decentralize the solution by allowing instances to vote, and following a majority vote, but if there are malicious nodes we have a problem.

Cheers,

Rafael Belchior

--

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com