I don't understand where actually the smart contract goes, when I click on create under remix.ethereum.org. If I choose for example the Injected Web3, this should publish the contract to the ropsten test net, right? But how can I access the contract then? When I use metamask it injects me the right provider when I use web3.js, but how can I find this contract now, if I don't want to use the injected web3, but manually choose the provider address in web3.js? Can I access the smart contract this way?
Edit: I don't know what should be wrong about my question.I seriously find nothing about how how to connect to a smart contract for example in the ropsten test network without injected web3. Normally you do this in web3.js:
if (typeof web3 !== 'undefined') {
web3 = new Web3(web3.currentProvider);
} else {
// set the provider you want from Web3.providers
web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
}
}
But if you don't have an injected web3, then you use the localhost. But I cannot connect then to the smart contract, because it does not know, in which net I actually published the smart contract, right?
Remix has 3 different environment options that can be used to deploy/test Solidity contracts: JavaScript VM, Injected Web3, and Web3 Provider. This option can be changed under the Environment drop down under the Run tab. (It looks like you've got this part...just documenting for completeness).
JavaScript VM: This is Remix's own internal sandbox. It does not connect to MainNet, TestNet, or any private network. It's an in-memory blockchain that can be used for simple testing and quick mining.
Injected Web3: This is the option to use for the browser plugin (MetaMask). Here, you are telling Remix to defer all control of the blockchain integration to the MetaMask plugin. At this point, MetaMask controls which network you are connecting to. In the plugin, you can connect to MainNet, Ropsten, Rinkeby, etc through Infura's node network. In this case, you're not running a node locally. MetaMask also has a localhost option where you can run your own node locally and MetaMask will send all transactions to it (this local network can be a private network using any node client or you can use a test blockchain like TestRPC).
Web3 Provider: This allows you to enter a URL in Remix to connect to the blockchain. The most common setup here is to be running a local node and connecting to it through it's IP/port. This is pretty much the same as using MetaMask's localhost option, but you're just cutting the plugin out of being the middleman. Just like option #2, the network your connected to depends on how you've configured your local node (it can be main, test, private, etc.).
So, "where your smart contract goes" depends on which of the configurations you have set up. Selecting Injected Web3 does not automatically mean your contract is being deployed to Ropsten. It depends on which network you have selected in the MetaMask plugin.
When using MetaMask through Remix, you need to use the plugin to select the appropriate account and confirm/reject transactions. Selecting the account is a bit confusing because Remix doesn't pick up all of the accounts imported into MetaMask. The Account dropdown will only have the account currently selected in MetaMask. In addition, if you change the account in MetaMask, you have to reload Remix for it to have that account selected in the dropdown. It does NOT automatically detect when the account has changed in MetaMask.
Once the account is properly selected (and assuming you're using an account that holds ether), you can now deploy your contract. Hit Create in Remix and then switch over to the plugin again. There, you should see a pending transaction waiting to approved. Select the transaction, then click Submit.
Transaction list:
Approve/Reject screen:
After submitting, it'll take a few seconds for the transaction to be mined. MetaMask will show when it's completed. That's it! To interact with the contract, you can initiate your transactions through Remix similar to the deployment steps above.
Related
How to deploy hardhat contract to mainnet without ALCHEMY or INFURA ?
Alchemy, Infura, and others, are services offering connection to nodes of the Ethereum network.
Contract deployment means that you broadcast a transaction with specific parameters (data field containing the compiled bytecode, to field empty). But you can only broadcast a transaction to the rest of the network from a node connected to the network.
So apart from using a third-party service, you can also run your own node. For example using the go-ethereum client software.
Then you'll be able to broadcast the transaction through this your own node, instead of a third-party one.
eth_subscribe method of JSON-RPC API requires a full duplex connection, such as WebSocket, hence subscribing to events is impossible via a HTTP connection.
I use Ganache as an ethereum node and Metamask as a browser provider to test my dapp. The Ganache server is listening to requests by means of HTTP. Nevertheless, the dapp have no glitches to receive notifications from the provider after subscription with eth_subscribe.
Have I got it right that Metamask, being encountered with a HTTP server, trys to get its events through any other way (like polling) deep under the hood? And then a dapp developer should not worry about whether the user's node supports duplex conections or not - as long as there is a Metamask provider. Or it's all Ganache - does it just support WebSockets?
I failed to find any clarification on this issue in the docs.
On spinning up a hardhat node locally, I get 10 addresses pre funded with 10k ETH. But none of these show up on metamask when I connect it to localhost:8545. As a result I'm not able to interact with a dapp deployed locally
Am I doing something wrong?
Usually, the back-end development project provides funded accounts which you can enter into Metamask, It's not like the Goerli or (now defunct) Rinkeby test networks where you can visit a site and have some ETH added to your test account because those test networks are hosted. You need to spin up a local project and have it provide funded accounts.
Such an example is Lesson 9: Hardhat Smart Contract Lottery in (Learn Blockchain, Solidity, and Full Stack Web3 Development with JavaScript by Free Code Camp)
here is the code ...
https://github.com/PatrickAlphaC/hardhat-smartcontract-lottery-fcc
If you run that project it generates a number of addresses which you can connect to in Metamask.
MetaMask has no way of knowing which of your local accounts you want to import, or which are funded (prior to the import).
So you need to import the accounts to MetaMask manually using the private keys provided by Hardhat.
I began to understand how to develop smart contracts on the Ethereum blockchain and how to write a web-script for interacting with a smart contract (buying, selling, statistics ...) And I came to the conclusion what to do. I wanted to know if I understood everything correctly.
We write the contract on http://remix.ethereum.org, check whether
all functions work correctly.
We are raising TRUFFLE + GANACHE to test a contract on our own
private blockchain.
We write a simple front-end to interact with the contract, we will
do everything through Metamask.
Deploy everything into the Ropsten Ethereum test network and test
everything there.
After successful testing in the test network, we fill everything
into the main blockchain of Ethereum.
Did I understand everything correctly, and did I take the right steps?
The steps you outlined look good. I would actually say that you don't need to do the first step, as you can use truffle during all steps of the development process.
Create a new Truffle project (truffle init) and write the smart contracts and migration scripts.
Write thorough unit tests using JavaScript (and/or Solidity) and run these tests on a local Ganache instance (truffle test). My library truffle-assertions can be used to assist in writing these unit tests.
Write a frontend to the contract which uses the artefacts generated by Truffle (truffle compile and truffle migrate). This frontend can be manually tested in the browser with Metamask.
Add connection configuration to the truffle.js file to connect with Ethereum Testnets (Rinkeby, Kovan, Ropsten) and Mainnet through truffle-hdwallet-provider and Infura, so the contracts can be deployed to these networks. Further explanation.
Deploy to a testnet of choice (truffle migrate --network ropsten) and do more testing as in step 3.
After you've thoroughly tested all functionality across the multiple development steps, deploy to the mainnet (truffle migrate --network mainnet).
Of course most of these steps can still be completed without Truffle, but Truffle really simplifies a big part of the process, and there is a lot of documentation/resources available for it.
Im implementing a ethereum PoA network using go-ethereum
I have deployed a ERC20 Token on the network, and the idea is that the network must be accessed from any wallet on the internet (i.e metamask, myetherwallet, etc)
The idea for this network is:
Having N full nodes that are able to seal blocks (the nodes has the unlocked accounts)
Deploy a smart contract that is a ERC20 Token
Having one node that expose the network in order to be accessed from any origin, for example, Metamask, MyEtherWallet, a mobile app with a wallet, etc. The idea is that anybody can hit the ERC20 Token if they have the appropiate client.
In order to achive that, i create 2 full nodes that are in charge of sealing the blocks.
I run those nodes like this:
geth --datadir sealer1/ --syncmode 'full' --port 30351 --rpc --rpcaddr 'localhost' --rpcport 8502 --rpcapi='admin,personal,db,eth,net,web3,txpool,miner' --networkid 20 --gasprice '1' -unlock 'someaccount' --password s2/password.txt --mine
As you can see, there are some important things about those nodes:
Unlocks the accounts
Are only accessed from localhost (note the rpcaddres)
Those nodes are miners
If i expose a node like that to the internet (enabling RPC access from any origin) any hacker could send the ether to another account, so, i create a third node, a standard node, that doesnt expose rpc apis but allows connections on port 8545 (in order to be hitted from metamask, myetherwallet, etc)
I run the node with this command:
geth --datadir standard1/ --syncmode 'full' --port 30352 --rpc --rpcport 8545--rpccorsdomain '*' --rpcaddr 'SERVER_PUBLIC_IP' --networkid 20 --gasprice '1'
as you can see this node:
Doesnt unlock account
Allow rpc accesing from any origin
Doesnt expose rpc apis like personal, admin, etc
My questions are:
is this aproach secure?
Is there another way to allow anyone in the world to use Metamask to hit my smartcontract without open the RPC access on the standard node?
Why i have those questions?
Because there are a lot of places that doesnt recommend open RPC ports, so im not secure if:
Dont have a node exposed with unlocked accounts
Dont expose critical rpc apis like admin and personal
is enough to expose securely my node.
Here are some issues related with opening RPC access:
https://blog.blockdaemon.com/ethereum-geth-configuration-made-in-ireland-7ba2e876c6e3
https://www.reddit.com/r/ethereum/comments/4z0mvi/ethereum_nodes_with_insecure_rpc_settings_are/
https://www.reddit.com/r/ethereum/comments/3ird55/holy_shit_my_eth_accounts_been_hacked/
https://www.reddit.com/r/ethereum/comments/4jav5u/mist_wallet_has_2_sec_vulnerability_for_rpc/
https://blog.3or.de/internet-wide-ethereum-json-rpc-scans.html
https://www.bokconsulting.com.au/blog/7218-ethers-stolen-from-miner-with-rpc-port-open/
https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/
Here the team lead of ethereum recomendation:
Ok, your setup seems insanely dangerous. --rpcaddr=external_address
essentially opens up the node to anyone in the world to access it.
Forthermore, --rpcapi 'admin,personal,db,eth,net,web3,txpool,miner'
permits anyone with access to do absolutely anything. I can imagine
someone from the internet is brute forcing the passwords.
https://github.com/ethereum/go-ethereum/issues/17417#issuecomment-413877558
is this approach secure?
You get the general idea, yes, but there is room for improvement.
First of all, I would never run a node that enables the personal API at the same time using -unlock which permanently makes the account accessible by anyone with access to your node. So imagine, someone has gained access to your node through some other doors, they would be able to immediately spend your funds from that account spawning transactions from localhost. Please, consider either only exposing safe APIs on that node or completely removing the unlock statement.
If you insist having the sealing nodes configurated as stated above, add some hardening. There are multiple options, you can use strong firewall rule sets to block basically everything from the outside network except for the node communications on port 30351. Or, what I would do, is hiding disconnecting this node completely from the public Internet and only wire through the p2p traffic from this node to some other proxy node which is connected to both, your node and the other nodes on the Internet. This could come with drawbacks in network stability though.
Is there another way to allow anyone in the world to use Metamask to hit my smartcontract without open the RPC access on the standard node?
Have you considered looking into public PoA networks such as poa.net? This basically allows your users to connect metamask or mycrypto to the already existing infrastructure of POA.