Is it correct that everyone can see my source code once smart contract code has been published to blockchain?
Is it correct that everyone can see application's businesss state and information saved in blockchain?
For example, the example below sends a request to blockchain, receives response from blockchain. In this case, can anyone see the source code and business information? The app uses Ethereum blockchain via Solidity.
https://learn.microsoft.com/en-us/azure/blockchain/service/send-transaction
Is it possible to protect source code and users can only see business states via UI? like conventional web applications.
Smart contract state and any information stored in the blockchain is visible to all observers outside of the blockchain, even local and private variables. (It is not necessarily visible to other smart contracts).
The solidity source code itself is not stored on the blockchain, only the compiled bytecode, which consist of low-level machine instructions (called opcodes) for the Ethereum Virtual Machine. Although this can't easily be converted back into your source code (i.e. all variable names will be missing), it does reveal information about what your code is doing.
In any blockchain the business info/state is visible to the participants of the blockchain network or consortium. Any smart contract state changes in done via a transaction that is shared between the participants of the transaction. Hence the contents/operations exposed via that smart contract is also visible to the participants of that transaction, so that they can verify it's validity / have a consensus on whether to accept/reject it.
To answer your question "everyone" may not be able to see the contents unless it is a public smart contract / transaction you are dealing with. in case of public transaction/contracts it is visible to that public chain. If it is a private transaction, then it is only visible to the participants of the private transaction.
Reference: Q&A
Related
I'm new in blockchain development, I wonder why is it necessary to interact with contract from another contract instead of from a personal EOA address?
Besides the delegatecall, I can't imaging any advantage to use contract to call another deployed contract's functions. As a user, I may rather use ethers or web3js through wallet etc to interact with a deployed smart contract instead.
would you please show me some reasons or necessary cases that I should design my project using a smart contract to interact with another smart contract? Thanks a lot!
There are too many use cases:
1- Upgradeable contracts or proxy contracts. Since blockchain technology is evolving so fast, it is so hard to write a contract that will be scalable. With proxy contracts, user calls the proxy contract but proxy calls the main contract. if in the future you have to change the logic of the contract, you deploy a new contract and make the proxy contract call this new contract. This way users will not get affected. You can read more about this pattern here
2- If you ever need to get data from real world, you cannot make an api call because this is not safe and not deterministic. for this reason, we use oracle services which also calls to many other smart contracts behind the scene, gets the results from each, and make a final response to the user. You can read more about oracles here
3- another use case is factory contracts. think about it as a class and users keep make an instance of it. that way instead of factory owner pays for the new contract creation, user will be paying for the deployment. you can read more about factory contracts
4- defi platforms have too many smart contracts and they are interacting each other. They keep the logic separate from each other, so they maintain better and see the missing points better. also putting everything in one contract would make contract code is bloated and make a mess. you can read uniswap
5- another use case to deploy library smart contracts. those are usually mathematical contracts which are deployed once and once u need complex functionalities, instead of you implement in your contract, you use library contracts and use them in your project. You can read about libraries
6- another use case is solving the scalability issues. imagine you have one kitchen and you have to serve all the customers from only one kitchen. As you get more customers, your service will eventually halted. so, there are layer 2 solutions to transfer some of the orders to different kitchens. and this of course happen through smart contract communications. more on layer 2
7- In general you can use inheritance. You deploy some contracts and inherit the logic from those smart contract. that is why you see openzeppelin contracts always inherit from each other
For example there are some standarts in Ethereum ecosystem. ERC20, ERC721, ERC1155 and others. So when you developing new project, instead of writing it from scratch you could install openzeppelin-contracts, import them and inherit. Afterwards you have this "carcass", on the top of which you can implement some additional functionality/custome code, etc. That approach is way more convenient and secure.
Another great example chainlink-contracts. Via them you can read from oracles. Oracles are smart contracts that keep track of cryptocurrencies prices online. Say you want your users to pay 10$ to participate in lottery/some giveaway. Your contract interacts with chainlink contract and makes sure that amount of eth that user paid is greater or equal to 10$ otherwise it returns error.
In solidity there is no true randomness, but again throughout interacting with chainlink contracts we can reach it. Another chainlink feature is automation contracts, check chainlink documentation to learn more(https://docs.chain.link/). To sum up id say that there is a lot of different protocoles/concepts which easier to interact with than to write it again.
"No need to reinvent the wheel"
I discovered a YouTube based scam where a fake Solidity tutorial instructs users to go into Remix and deploy a scam contract. The scam contract allows any address to withdraw the funds. It has fake comments that are hilarious, but it is really scary that this scam targets potential new people in the space.
How do I find the matching contracts from the compiled bytecode? I want to see on the blockchain which contracts match this so I can find the offending address that reaches out to claim.
If there a method in geth? What about a scanner? Maybe The Graph and a subgraph?
Should I just download the chain and query? The problem for me is chain bloat and syncing Ethereum will take forever.
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.
I am studying blockchain with Ethereum, and I want to use past transaction data in the Smart contract using Solidity.
If I use Web3.js module in the program written in javascript, I can get these data easily.
But I can't get these data in the Smart contract using Solidity.
Reference of Solidity says that we can get current block number, blockhash, etc., by using "block.number" and "block.blockhash(uint blockNumber)" functions, but doesn't mention getting transaction data.
(http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#special-variables-and-functions)
please help me.
The answer is simple. Unfortunately, you simply can’t access old transaction or block data onchain from Solidity. At most, you can access hashes of last 256 blocks (see blockhash in documentation )
Alternatively, as a workaround you could consider using Oraclize. Oraclize represents way to read offchain data onchain, so you could try to read transaction data from Etherscan web API. The way Oraclize works is that :
You request to Oraclize smart contract what data you want to fetch from internet (some URL)
Oraclize offchain servers then detect your on-chain request
The look up the data you wanted (they'll make some http request to the URL you provided)
Once they get response, they will send transaction to your contract (calling specific callback method) containing data you requested
With such approach however, you are relying that:
EtherScan is up and running
Oraclize is up un running.
If you only care about transaction data related to your smart contracts, another way would be to store that transaction data onchain. Maybe we could gave you some more suggestions if you tell us more about what specific problem are you solving.