Regarding the Whitepaper / Besu Connector - Rafael Belchior

Rafael André Pestana Belchior

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.


Rafael Belchior


Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa