To interact with a smart contract, your DApp needs the contract's:
If you're not connected to the right network, you can't send transactions to your contract. Many DApp developers deploy their contracts to a testnet first, in order to avoid potentially disastrous fees if something goes wrong during development and testing on Mainnet.
Regardless of which network you deploy your final DApp on, your users must be able to access it. Take Ethereum as an example. You can use the wallet_addEthereumChain
and wallet_switchEthereumChain
RPC methods to prompt the user to add a chain that you suggest, and switch to it using a confirmation dialogue.
Every account has an address, whether an external key-pair account or a smart contract. For any smart contract library to communicate with your contracts, a smart contract must know the exact address.
Take Ethereum as an example, the ABI specification is a way to encode the interface of a smart contract that's comprehensible to your user interface. The ABI is an array of method-describing objects, and when you feed this and the address into a contract-abstraction library, the ABI tells those libraries about what methods to provide, and how to compose transactions to call those methods.
Example libraries include:
If your DApp publishes a new pre-compiled smart contract, it might need to include some bytecode. You don't know the contract address in advance; you must publish the contract, watch for the transaction to be processed, and then extract the final contract's address from the completed transaction.
If you publish a contract from bytecode, you still need an ABI to interact with it. The bytecode doesn't describe how to interact with the final contract.
If your DApp allows users to edit smart contract source code and compile it, similar to Remix, you can import a whole compiler. You derive your bytecode and ABI from that source code, and eventually derive the contract's address from the completed transaction, where that bytecode is published.