After reading and searching online, I still have many doubts about how EOAs work and their relationship with smart contracts.
The idea behind my dapp is to allow users to make reservations. It also offers a refund of the payment if certain conditions are not met.
I know that I have to implement a component in web3.js that sends the transactions (which I decided to call contract manager) and the smart contract in solidity. I have doubts about how to start the process.
My idea is that there is only one EOA (which I assume is in the contract manager (?)) that collects customer data (customer id and payment) and sends it via transaction to the smart contract.
My questions are:
- Is it possible to have only one EOA that collects all the front-end requests (customer id + payment)? Is this id the customer's EOA? So an EOA (contract manager) that collects many EOA + payment?
- Must the payment of each client (which is collected by the contract manager) be in ether or in real money?
- Is it correct to say that my contract manager (implemented with web3.js) owns the only EOA that sends transactions to the smart contract?
Best Answer
This touches several parts of how Ethereum works. I'll try to explain it in an understandable way:
1.) Ethereum has "externally owned accounts" (EOAs) and "contract accounts". EOAs are much like normal bank accounts. They have an address (IBAN) and a balance (in Ether). Essentially, the EOAs owner possesses a public key pair, of which only he knows the private key. The matching public key "is" the EOAs "address" - the "IBAN". Now, only the EOAs owner can transfer Ether (="withdraw or wire money") from that account - by using the private key in the process. In short, EOAs are "directly owned and controlled" by their respective owners. Contract accounts do not "belong" to anyone. They simply exist on their own and store smart contract code. They also have an address etc, but noone possesses the matching private key. Therefore, the comprised smart contract logic controls the contract account. For a better explanation see also: https://github.com/ethereumbook/ethereumbook. Consider buying the book if you work with Ethereum. It is worth every cent!
2.) The scenario you describe could have a smart contract (i.e. contract account, not EOA) that accepts payments from customers (i.e. from EOAs) and then stores a list of who (= which address) payed. In a smart contract, that can be done e.g. via a
mapping. The money payed to the smart contract can then be forwarded to the "business owner's" address (EOA).So all in all, to your questions:
3.) Depending on what you want to do exactly, you can also issue a (non-fungible) token for reservations. Customers who want to "buy" a reservation buy a token. See, e.g. https://ethereum.org/en/developers/docs/standards/tokens/erc-721/ for a standard for such a token.
4.) Anyhow, consider the fact that storing personal information on the blockchain is bad practice, as everything is public and cannot be deleted afterwards. A better approach might be one where your customer pays you (e.g. in ether) and you then issue a so-called "verifiable claim" for him, stating that you confirm his reservation and payment. This happens off-chain and only a hash is stored on the blockchain. The general approach is called "Self-Sovereign Identity" (SSI). See systems like "Sovrin" or "uPort" if you want to follow up on this. https://medium.com/uport/erc1056-erc780-an-open-identity-and-claims-protocol-for-ethereum-aef7207bc744
Hope this could help you.