10

It is not possible as on 24th March 2018. Etherscan is unable to locate contract code on the address of subcontract. Here is the transaction which deploys two contracts. But for the second contract, etherscan is unable to find contract code. The second contract does exist and this was verified by using "at address" feature of remix. Until there are some ...


5

This was already answered in the comments to your own previous question To summarize: The transaction that created the contract is visible on Etherscan (example here) The input data to that transaction, which is mostly the compiled bytecode of the contract itself, also contains the constructor parameter values in the last bytes (32 bytes per parameter) ...


5

I deployed the contract on the Kovan test net. Deployment versions same as you. Everything worked properly. I see no reason for it not to work on Ropsten. How did you deploy the contract? Maybe share the address to I can try to verify it.


4

I have deployed a contract from another contract: https://etherscan.io/tx/0x8fd885ce7ad7b6a591d9614d41cbb1d97aa7d2e290f6aa52531ce3d4c799a5ff which deployed: https://etherscan.io/address/0xb1400278014f34c8243b15613a4b463b51fb6f2a#code and I was able to verify contract using the same compiler version and optimization. You have to encode all constructor ...


4

You can use assert (over require) to indicate your intention to source code analyzers such as oyente. While require is good to validate input, it can sometimes be false because the user did something innappropriate. assert, on the other hand, is meant to indicate something that should never be false under any circumstances. Knowing this, a source code ...


3

In order to deploy contract on MyEtherWallet, you need the bytecode. The bytecode contains the solidity pragma version in the metadata which is converted into the object parameter in the bytecode you get itself. It will compile using whatever is set as the pragma. As for verification. You will need to know what pragma was set in the solidity code itself. ...


3

Yes, you can use this tool: https://abi.hashex.org. It can automatically parse constructor parameters from ABI or you can add them manually. After you enter parameter values, ABI-encoded parameters string would be automatically generated, so you just copy and paste it in etherscan.io constructor parameters input.


3

I was able to verify my contract with optimization turned on, when compiling from remix: https://ethereum.github.io/browser-solidity/ For some reason, it produces a different bytecode from Parity, even if you select the same compiler version and the same optimization setting.


3

Those are predeployment suggestions to reduce ambiguity at this step. The issue is there no way to be certain how the bytecode was generated because the pragma allows flexibility. If possible, examine the tools you used to compile, e.g. solc, Remix or truffle-config.js to work out the compiler version that must have been used. If you cannot do that, then ...


3

tl;dr: you should use both (and more) :) Different FV/static analysis tools often have different features and pros/cons which might complement each other and give you better coverage. In this case, for example, Manticore targets EVM bytecode whereas SMTChecker targets Solidity code. Targeting Solidity is better for high level properties, contract invariants ...


2

You were trying to verify the "Migrations" contract that you used in your truffle configuration. You incrementer contract was the next contract you created, and can be found here: https://ropsten.etherscan.io/address/0x8705c513da621a16fd1defc9de8ae7cdead01fb8#code I verified it for you, using the Optimizer but setting it to 0 optimizations. You were using ...


2

Per https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md#transfer: The function SHOULD throw if the _from account balance does not have enough tokens to spend. So I'd say you should indeed use require, but don't include the _amount > 0 clause. From the same documentation: Note Transfers of 0 values MUST be treated as normal ...


2

An easy way to find the constructor arguments is: Browse to your contract on Etherscan and click on the tx hash for its creation On the top right, where it reads "Tools & utilities", click on the arrow to see more options and select "Parity Trace" For the action pertaining the contract creation, click on "Show more" below to see the input/output On the ...


2

Miners want to win future blocks. If they don't independently verify that the chain they are following is the right one, they may end up spending future money doing proof of work on an incorrect chain. As soon as they see the winning block hash from some other miner, they confirm it, add the new block to their own chain, and hurriedly start trying to win ...


2

How i can do that ? Generate flat sol file from your two source files, for example, with solidity-flattener. Insert content of this flat file to "Enter the Solidity Contract Code below" field Choose the version of compiler you used in Remix Choose optimized flag true/false depending on what was this flag switched or not in Remix Copy contract name from the ...


2

I don't think your question is unclear (someone flagged it) but it's pretty far off from the way Ethereum works conceptually. Let's start with the big one. Everything in Ethereum is deterministic, meaning it is possible to verify correctness. In fact, it must be possible for every node to verify every computation now, and in the future. Consider this ...


2

The semantics of Solidity change with every update, and the only canonical definition is the compiler itself. Note that there is a distinction between the intended behavior of the compiler and the actual behavior, which sometimes leads to compiler bugs. Maybe then it is more accurate to say that the (informal) definition of the solidity semantics is in the ...


2

There's a link on the right-hand side (in "Profile Summary") labeled "Contract". Click that, and then, assuming there's verified code available, you should see a tab for the contract's code. (You should end up at https://etherscan.io/address/0xa74476443119A942dE498590Fe1f2454d7D4aC0d#code.)


2

It depends on what you mean by "safe". You can confidently derive the source code of this contract by the source code of the deployer. It will normally happen from a statement in the form of new Contract(arguments) and analysis of the deployer contract will leave no doubt about what it does. It does not mean that the quality of the contract or the intent ...


2

It looks like you just deployed this contract recently. I would suggest upgrading your compiler to the latest (0.5.10 at the time of this post) or at least the latest 0.4.x compiler and redeploying. Not only will you be able to verify your contract code on Etherscan, but you won't be subjected to all the compiler bugs that existed in those old versions.


2

The blockchain is an internally consistent data structure. It is deterministic so that all nodes can verify the transitions. It cannot see the apples. That is an external reality. Generally, this is sometimes called the onboarding problem - how to get information from the real-world into the blockchain. It is a common design challenge. in the simplest ...


2

You're right to note that this is an issue when flattening source code for Etherscan verification. There are two solutions to this. The best solution is to not flatten the source code and instead use Standard Input JSON for verification. Most tooling plugins support that by now (like truffle-plugin-verify and hardhat-etherscan). If you're not using any of ...


2

The transaction will be included in the blockchain the moment it is included in a block (at least from the miner's perspective), so it doesn't need to "wait" for other nodes to verify it first. If the miner is dishonest and the transaction result is not calculated correctly the block will be ignored by others. Miners can choose which transactions ...


2

Short answer is: you have to create the API key at etherscan.io either for the mainnet and the rest of public testnets (Ropsten, Rinkeby, Goerli..). (Bonus) In addition, I had some issues when trying to verify a contract with interfaces located in subdirectories. Perhaps it is not your case, but if you are using Truffle to manage the contracts deployment, ...


2

The bytecode is not CBOR-encoded as a whole. Only the part representing the metadata hash at the end is and you seem to be decoding it correctly. As to why it can start with 0xa264, 0xa265 or something else see my earlier answer for "How to verify smart contracts on different solidity versions". Am I right to distinguish runtime bytecode and ...


1

Contracts cannot access someone else information on their own. They can call other contracts to acces information but only when someone else instructed them to do so. For example a smart contract cannot move ERC20 tokens that belong to someone else, but if the owner has approved them they can move them. Is the responsability of the contract holding the ...


1

mining : The ethereum main net uses, untill now, the Proof of work as a mechanism of getting the blocks(transactions inside) agreed upon and added to the blockchain. The proof of work requires the nodes in the network to do some work in order to prove their "will to be part of the network". working and succeeding in completing the task is rewarded by ...


1

It's done. You were most of the way there with your ABI-encoded constructor arguments. It was necessary to copy the complete source from your verified factory to get it to compile, then pick out the StillBank contract. It would have to be the same compiler version that made the factory, leaving only the optimization to guess at. Hope it helps.


1

It depends what you mean by manual testing. You could paste the contract into Remix for superficial testing. http://remix.ethereum.org. That would help you discover that the deposit() function doesn't accept deposits. It might not help you discover that the contract contains an anti-pattern and a re-entrance vulnerability because a state-change takes place ...


1

We can see the application of a number of interesting formal verification tools and frameworks on Ethereum lately. In the event of rising attack vectors against the smart contract security model of Ethereum, formal verification has become a strong imperative. Initial efforts were based on Coq proof assistant. Nowadays we can see the adoption of K-framework ...


Only top voted, non community-wiki answers of a minimum length are eligible