1

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?
1
  • you can collect in DAI tokens or USDC tokens, these are real US dollars
    – Nulik
    Feb 3 at 16:23
2

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:

  • No, you would have a contract account accepting reservations
  • Technically, you can also have a payment via VISA and just store the "receipt" in the chain. Wouldn't advise you to though!!! You can also go and use your own reservation token. I guess paying in Ether is the best approach here. Anyhow: Why are you thinking about implementing this in Ethereum in the first place?
  • Your web3.js simply sends transactions to the blockchain. I guess you would have a web-app which allows a customer to make a reservation which is then payed (and recorded) on the Blockchain. Here, the customer would use his wallet (e.g. Metamask) to pay to your account, and your backend would listen to an event telling you that the reservation and payment went through.

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.

4
  • 1
    thanks you were very clear and helped me a lot, but to make sure I understood what you said, I would like to ask you some questions. - Do users interact directly with the smart contract and send their bookings through transactions? - When you say "the customer would use his wallet (e.g. Metamask) to pay to your account, and your backend would listen to an event telling you that the reservation and payment went through" what do you mean by "your account"? - Who is calling the functions of the bookRequest smart contract? is the backand component to be implemented in web3.js?
    – Mario Roma
    Feb 3 at 18:27
  • when you say "pay to your account, and your backend would listen" is the account and the backend the same thing? I'm trying to design an architecture but I can't figure out what components are needed.
    – Mario Roma
    Feb 3 at 22:22
  • I read your answer again and maybe I didn't explain myself well. I am not interested in who receives the ether i.e. the hotel / any other account. I'm just interested in knowing what happens on the customer side. So I want to understand: do customers interact directly with the smart contract? I mean are the customers calling the bookrequest method on the smart contract? or is there another component that owns the contract accounts to do so? If this component exists is it written with web3.js?
    – Mario Roma
    Feb 3 at 23:20
  • Well, these are a lot of questions. I'll try to answer in order: 1.) Whether customers directly interact with your smart contract or not depends on your design of the smart contract. 2.) "Your account" in this example means your EOA as the business owner. 3.) no! account == EOA and backend == code/db on a server. 4.) Again: it entirely depends on how your contract is going to be designed!
    – Xenonite
    Feb 15 at 12:23
1

An EOA has always a private key to sign the transactions. So if you plan to use one common EOA (your backend manager) then the sender of all transactions would be that EOA - and that one would also pay all gas fees.

If you wish to get some Ethereum assets (either Ethers or some tokens) from the users as payments, the users need their own wallets (EOA) from where to pay the assets. And then they'd send a transaction to your common EOA with the assets. But then it would already be easier if they simply send their transactions to your smart contract, without a common EOA. The users could also input some unique ID of theirs when submitting the transaction.

If you want to take non-crypto assets, then you need to figure out some way to deal with them - that part has nothing to do with the blockchain.

6
  • Thank you very much for your reply. I was thinking of using only one EOA to send the transactions, in order to have better security. In this way the smart contract can check that the transactions come from that single EOA. Is it wrong? But in a real case, can a user interact directly with the smart contract?
    – Mario Roma
    Feb 3 at 14:22
  • 1
    Users can interact directly, unless you have some sort of whitelisting in the contract. If you do have whitelisting, you can whitelist only your EOA, and therefore only that can interact with the contract Feb 3 at 14:25
  • So let's assume that each user can interact directly with the smart contract. From an implementation perspective what is the component that needs to be implemented in web3.js to allow for transaction creation and interaction with a geth / parity node or an Infura service?
    – Mario Roma
    Feb 3 at 14:36
  • 1
    Probably the users use Metamask to connect to the blockchain. So you need to implement functionality in web3 to call the contract through Metamask's connection Feb 3 at 14:38
  • to try to understand I was reading this document link and on page 18 the architecture is shown. On page 22 it says that "to allow for automated testing with multiple simultaneous submissions, the test suite emulated passengers by generating an EOA for each of them, as shown in Figure 3.1. To facilitate this automation, Metamask was replaced with a geth client and web3 .js." I think this has confused my ideas. I don't understand who among test suits, contract managers, passengers is implemented in web3.js
    – Mario Roma
    Feb 3 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.