I created a genesis.json file - private network(Ethereum).
for some reason, I want to allocate new ETH to new Addresses(like I did before at the genesis file).
my question:
if I change the genesis file and re-create the network, are all the eth that transferred to other wallets will be lost? (all the database will be lost?)
OR
there is a way to dynamically upgrade the genesis.json file?
if there is a way in the PoA/PoS/PoW Ethereum network please let me know
You can't.
The genesis.json describes the chain state at the beginning. Once blocks are mined on top of this chainstate, it cannot be altered, or it would render the entire chain (all the blocks) invalid, and you would be on a brand new network.
In a PoA network, you are supposed to pre-allocate as much ether as required, and use regular transactions to send that to new addresses as needed. It is a good idea to overallocate at the start, and set up a faucet system to make distribution easier.
Related
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
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.
Next week I'm starting on a new blockchain project using Hyperledger Fabric. I have a question regarding the configtx binary.
We use this binary to create a channel.tx and a genesis.block. I have read the documentation, watched tutorials and looked on the internet but I still don't understand why the genesis.block and channel.tx is needed an why it's created like this. For example: shouldn't the genesis.block be in the blockchain including the channel configuration?
A simplified answer:
A genesis block is referred to as the first block.
The first (genesis) block in a channel, is a channel.tx (channel configuration transaction). It doesn't contain much more than the name of the channel, and the consortium that is allowed to use the channel.
The orderer genesis block is what configures an orderer when it starts. It contains MSP IDs for each organization, which MSP IDs are part of a consortium, and a trusted certificate for each MSP ID.
The orderer needs information about organizations, because the orderer approves the creation of new channels. A channel creation request must come from a trusted entity (part of an organization), or else the channel will not be created.
Since you cannot modify (execute a transaction) in a channel without an orderer approving, it makes sense to only let the orderer have the network information. This way you don't risk having inconsistent information between channels/orderers in case anything changes.
All Fabric blocks are encoded/serialized using protobuf, as the internal communication relies on gRPC. A block is thus in a binary format.
Think like this, what would you do if you want to change the configuration of the blockchain system? shutdown all the host, edit their config and restart them one by one? That will be rediculous, because we say that blockchain is decentralized, nobody can control all the hosts. The only way to change configurarion dynamically is consensus online. So how to make consensus online, obviously, the answer is using transactions(tx). As for the initialization of the blockchain in frabric, we can use the same way , that is channel.tx and genesis.block, to eliminating the cost of initialization by reuse the logic of editting configuration. Meanwhile, tx should be placed in a block, so that is why genesis.block exist.
I'm attempting to create a private PoA ethereum network and I've been using morden, ropsten and rinkeby for a while. I didn't realize before that network nodes discovery is made by a connection to some bootnodes. Are these nodes central? And thus, isn't it a big decentralization lack?
I mean, if bootnodes are only few and are set at the beginning of a network creation, we can imagine that those nodes are fraudulent (in the sense of pointing to fraudulent BC nodes). No?
Thank's in advance for your replies
Yes, the bootnodes are central, and for the main and test networks are hardcoded in bootnodes.go.
The "enode://" protocol includes the public key as well as the IP address for these nodes, so you're still effectively trusting the Ethereum Foundation, but it should be secure. From there additional peers will be shared with your node.
Some more details on how connectivity works can be found on the wiki here.
I've seen/heard developers talk about Ethereum test nets, but I've just been publishing to the public block chain. What is a private test net and how do I set one up?
A private testnet is your own personal, local-to-your-machine blockchain to mess around with. Publishing to the public chain is slow and creates bloat. Plus, you have to use real ether to do anything. A private test net avoids these issues.
Setting up a private testnet is easier than you’d think.
geth --rpc --rpcaddr "127.0.0.1" --rpcport "8545" --dev --mine
This says, “start a geth instance with JSON RPC (for web3.js interaction) at the given IP and port, create a private chain and start mining it.” In the log, you should see lots of the hammer icons, signifying that you’re mining your private chain’s blocks. (CPU-only mining is sufficient because the difficulty begins so low.)
When you type “geth attach” per usual in another terminal window, you’ll see that all of your accounts balances are zero except your coinbase which is rapidly filling up with fake ether. Don’t worry. Your accounts aren’t really zero. All their “real” values will be there if you connect to a “real” geth instance and the public blockchain.
Now you can interact with your private test net just as you would the public one.
A diffrent way to setup a private Network is to use testrpc. This kinda simulates a ethereum Network by providing a local client that acts as if it is connected to a network for development and testing. The advantage is, that it is very fast, but it will not presist the state of your network as it operates completely in memory.