How can I update the smartcontracts of my Truffle dapp which are deployed in the Ethereum blockchain?
Great answer found here.
From axic in Ethereum Stack Exchange site:
Contract code is immutable, the storage is mutable, but you cannot
execute code placed into storage, at least for now.
Bugfixes to contracts
As for bugfixes, the common pattern is to have proxy or lookup
contracts to be a gateway to the real one, which in case of a change
or bugfix would be replaced. Replacing it also means losing the old
storage contents.
Keeping storage
If you want the ability to upgrade code, while keeping storage, you
could think of separating storage and logic. Have a dedicated storage
contract, which accepts write calls from trusted addresses (e.g. the
logic contracts). All important storage should be associated with this
one.
Accessing storage after selfdestruct
As of today there is no real pruning implemented even in the case of
selfdestruct, but that should definitely come in the future. There are
several EIPs discussing this.
Even if pruning is implemented, it shouldn't happen in an instant and
you should be able to read storage from the last state. It is also
planned to have archive nodes to keep states indefinitely -- not sure
that is feasible without limitations just by judging at the growth of
the blockchain.
Redeploying at same address
In short: practically this is not possible. The contract addresses are
calculated from the sender and the nonce. The nonce is sequential,
there cannot be any gaps and there cannot be duplicates.
In theory it is possible to arrive at the same hash with a different
nonce and address combination, but the likelyhood is small.
Related
I have a newbie question. As I understand, ethereum internal transactions are not stored on-chain. One can replay them when replaying the blocks. This seems to assume that smart contracts' behavior is deterministic. What if there are oracles? Does that make the smart contract's behavior nondeterministic and therefore one can't always replay the same internal transactions?
A blockchain oracle is any device or entity that connects a deterministic blockchain with off-chain data. The way they work is these oracles actually enter data on the blockchain through an external transaction. this way we can guarantee that the blockchain has all the information needs to verify itself. So instead of calling an API, an off-chain oracle will actually get the API and then report it on chain in a transaction. that way there is no API calling in the ethereum. Oracles are known as blockchain middlewares as they bridge the blockchain world to the real world.
Oracles are trusted entities because they are capable of digitally signing or digitally attesting the data to prove that the data is authentic. This proof is called proof of validity or proof of authenticity.
Oracles should not be able to manipulate the data they provide and must be able to provide factual data. Even though oracles
are trusted, it may still be possible that,
in some cases, the data is incorrect due to manipulation or a fault in the system. Therefore, oracles must not be able to modify the data. This validation can be provided by using various cryptographic proofing schemes. Some mechanisms to produce proof of data security:
TLSNotary
Android proof
Ledger proof
Trusted hardware-assisted proofs
DEcentralized Oracles:
As blockchain platforms such are fully decentralized, it is expected that oracle services should also be decentralized. This type of oracle can be built based on a distributed mechanism. For more You can read here:
https://medium.com/stakin/the-top-decentralized-oracles-169b94dfbb83
Using OpenEthereum, which is the json rpc call allowing to do it?
I found the parity_pubsub module but I ve no idea of the parameter for getting not yet confirmed transactions.
I also found https://web3js.readthedocs.io/en/v1.2.11/web3-eth-subscribe.html#subscribe-pendingtransactions in the web3 module but it doesn t allows to filter transactions and the documentation doesn t explains how to use the full web3 api along OpenEthereum.
The purpose
The aim is to frontrun transactions for arbitrage by always maintinning the highest gas price until the next block is mined.
This involve detecting competiting transactions (those targetting the same Ethereum address as mine and with a higher gas price than me) with the lowest latency as possible in order to replace them as soon as possible (either for abortting the trade or changing the gas price again). So this exclude constantly polling for the answer as the requirement is to have the lowest number of context switches.
I want to know the exact effect of submitting a smart-contract call. For example, if I swap USDC to ETH on uniswap.
For transactions, we have eth_call, is there something similar for contracts? This needs to work for arbitrary complicated interactions, basically anything I can sign and submit.
I have a fully synced node, so everything can be done locally.
Ganache in-memory Ethereum testnet supports forking a mainnet.
Ganache allows you to "unlock" any Ethereum account, so you do not need to have necessary private keys to sign transactions to simulate actions.
late answer but I recently had this problem and so I've developed a tool to solve it.
You can simulate Ethereum transactions on the mainnet with Pelta Shield.
This tool allows you to see the usual tx info (such as what you would see on Etherscan) before the transaction actually gets included in a block.
In fact you can even abort the simulated transactions if you don't like the result of it, and you will not pay any gas.
Note that the results of the simulation will only be accurate as long as the transaction doesn't depend too much on the live state of the Ethereum blockchain.
If the state of the blockchain changes between the simulation and the actual execution, the simulation may not accurately reflect the result of the transaction.
DISCLAIMER: I am the founder of Pelta.tech, the startup that developed Pelta Shield, so I'm definitely biased in my recommendation.
I'm a product manager not a Blockchain coder, looking for a 2nd opinion and some general good practice advice. I have one question in bold, the rest is background.
Background:
We have an app in development that will write user's information into a Smart Contract on the ETH blockchain.
The SC's we deploy contain information only, no Ether.
Each user has their own SC which stores only that users specific information.
Our App allows the user to edit and update this information and then upload the changes, encrypted, into their own SC.
The user's SC address is 'tied' (sorry for lack of correct terminology) to their own Ether wallet.
I see on Etherscan (Ropsten) there is a Contract Creator address which is a constant for all the SC's our App creates.
I'm assuming that the contract creator address is unique to us, it is code we've created and as such it deploys only our Smart Contracts on behalf of our Application.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
My Concerns:
Should there be an exploitable flaw in our code then a bad actor has a list of contract addresses to attack.
The worst-case risk to us is that a bad-actor could access each users data in an unencrypted state if a flaw exists in our publicly accessible code.
The Bad-Actor then uses that flaw and the list of smart contract addresses they can get from Etherscan to download multiple users data.
My Question
Are these realistic concerns?
If so what general directions can we look at to mitigate these risks
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
The developers are outsourced 3rd parties and excellent people to work with. But Im looking for an alternate opinion than just theirs at this time as a double check.
Apologies if the information Ive provided is confusing or incomplete.
Thanks in advance for your time.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
As you have addressed here, data regarding the blockchain (i.e. transaction hashes, contract addresses, and user addresses) is transparently available. This is by-design with Ethereum and allows for the traceability aspect of the ledger.
Furthermore, smart contract data is potentially available to any actor in the Ethereum network. However, that is based upon the following:
In order to access the smart contract data, an actor would require the contract ABI. This interface allows code to be written to interact with the smart contract methods. Now, it is helpful to understand that this ABI could hypothetically be easily reverse-generated with enough details of how your DApp interacts with the existing smart contract.
If your smart contract logic has exploitable flaws, a malicious actor on the network could take advantage of this. This is why contracts should be well-written and unit tested with near (if not) 100% code coverage. You should also identify the potential actors in each contract scenario and be sure your test cases appropriately cover these scenarios.
If so what general directions can we look at to mitigate these risks
Given the contract scenario you have described, if the only actor who should have access to these user data smart contracts is the user them self, then you simply need to apply something akin to a function modifier to your smart contract logic. In the linked example, access to the smart contract data is restricted to a single specific Ethereum user address.
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
Sure. It sounds like you're currently using a single account to deploy the smart contracts, hence the creator address is constant. (Side note: I'm not sure why you're deploying the contract on behalf of the user with this account, it sounds like the user should be deploying their own smart contract). Regardless, you could simply create a new proxy user address each time you deploy the smart contract. However, I don't see any benefit to doing so and this would just be an example of security through obscurity.
We are thinking of building a dapp for finding salon near me and allowing booking. In such application end users has to be shown the salons which are at a certain distance from their current location. Where would be query that data from. Cause I don't think so that kind of querying is possible in solidity. Do we need to bring in any RDBMS in such a scenario to store salon data so that we can query it easily and booking information can be sent to blockchain.
Is hybrid application the only way out? People are talking about IPFS should be used for storing the images, videos and other data. Is that the solution, if yes then how would we query it from there? Moreover, would it be fast enough?
TL;DR: Short answer: you might, but you shouldn't.
The real question here is what do you need ethereum for in this project?
In Ethereum, each write operation is costly whereas reading data isn't. Write operations are transactions, read are calls.
It means that "uploading" your salon list will cost you money (i.e. gas), but also each data update (opening hours, booking ..).
For the mysql specific part of your question, well Ethereum is not designed for that kind of operation.
Something with an oracle might do the trick but it's truly not designed for. See Ethereum like a way to intermediate transactions between peers that stores every transaction publicly and permanently.
According to the Wikipedia page blockchains are basically a "continuously growing list of records". Ethereum has the possibility to make workers run some code in exchange of gas.
This code (or Smart Contract) only purpose "to facilitate, verify, or enforce the negotiation or performance of a contract" (here contract is a legally binding contract).
From what you described, IMO a simple web application with "standard" SQL is more than enough.
You just have to store the salons' GPS coordinates and do the closest match(es) from the user's GPS coordinates.
You likely want to separate your application into two parts:
- The part which shows the available booking times
- The part which makes a new booking