I have tested the demonstration of the subject according to the documentation. Two questions in my mind.
(1) I notice that there is no EOA (enduser owned account) for the sequencer. By inspecting the network I only see the four ethereum addresses for the four nodes. When update is made on the ledger, what account does the sequencer use? I assume we need the private key to sign the transaction when updating the ledger in Besu.
(2) In real life we may be given a running Besu network and an EOA for the sequencer. It is not difficult to deploy the bytecode of sequencer on a runnning network. Where can I specify the EOA (i.e. private key and account) used by sequencer? Just a quick comparison, in Fabric we need to specify the credential of Admin for the sequencer. Just look for something similar in the Ethereum/Besu setup.
(1) I notice that there is no EOA (enduser owned account) for the sequencer. By inspecting the network I only see the four ethereum addresses for the four nodes. When update is made on the ledger, what account does the sequencer use? I assume we need the private key to sign the transaction when updating the ledger in Besu.
Canton’s Ethereum integration uses a multi-reader multi-writer configuration, so there can be multiple sequencer nodes, where each sequencer node is basically a JVM process. Each sequencer node currently uses a new, randomly generated set of credentials because we currently run on a free-gas network. Picking your own ethereum account to use for a sequencer node isn’t supported at the moment, though I wouldn’t expect it to be difficult to add to the integration.
(2) In real life we may be given a running Besu network and an EOA for the sequencer. It is not difficult to deploy the bytecode of sequencer on a runnning network. Where can I specify the EOA (i.e. private key and account) used by sequencer? Just a quick comparison, in Fabric we need to specify the credential of Admin for the sequencer. Just look for something similar in the Ethereum/Besu setup.
You can’t specify the EOA account for the sequencer node at the moment, you need to configure a free-gas network so a new account with no ether will work.
Thank you for asking this question, I’ll update our documentation to be more clear
A follow-up on (2). If a customer has a running gas-free besu network, i should be able to
(1) deploy contract (bytecode is available in the example)
(2) obtain contract ID and configure it for the sequencer
I am drafting the process to deploy sequencer in a running Besu. See if this works.
Besides, I suppose the contract should handle well that only sequencer can update the states, as the access control is not at EOA address level. If not, anyone can write anything on the contract once the contract ID is known.
Preformatted textA follow-up on (2). If a customer has a running gas-free besu network, i should be able to
(1) deploy contract (bytecode is available in the example)
(2) obtain contract ID and configure it for the sequencer
I am drafting the process to deploy sequencer in a running Besu. See if this works.
Yes, you should be able to deploy the Sequencer.sol solidity contract using the provided binary, and you can put the Sequencer.sol contract address in the configuration file for the Sequencer node.
Besides, I suppose the contract should handle well that only sequencer can update the states, as the access control is not at EOA address level. If not, anyone can write anything on the contract once the contract ID is known.
The Sequencer.sol contract does not perform access control: anyone connected to the ethereum network can request that some data be sequenced. In this sense, access to the ethereum network itself should be controlled, as is usually the case for free-gas networks. The Sequencer.sol contract does perform the “logic” of sequencing itself, so this logic is always enforced.
Regarding the Authorization part, I’m checking my understanding. In summary, this provides a whitelist of Ethereum addresses that can call functions. In practice they are the wallets configured in the sequencers. See if my understanding about Authorization is correct.
If so, there are two questions to follow up.
It is written in the doc that Initially, only the Ethereum account which deployed Sequencer.sol is authorized. In the demo the contract is preallocated in the genesis block. In this case who are the wallets address in the whitelist initially?
I’m reading the Sequencer.sol provided in the code and unable to locate where the whitelist is implemented. The closest one is member in the solidity code but it seems it’s not address (it is string). Can you point me in which part the on-chain authorization is done.
your understanding about authorization is correct; in practice the accounts on the whitelist should be those accounts used by the sequencers. However, authorization will only be available in the minor Canton release (so 2.1.) and this is why you can’t find it in Sequencer.sol. The demo also changed to accommodate authorization - the account of ethereumSequencer1 is the initial account. (As a DA employee, you can preview this via downloading the enterprise dev release package.)
