Update:
Starting right now, there will be a large amount of development updates as we near the June 28th release date of the Test Network. These will be technical in nature, but explains the work going into Qtum Core.
We'll start with the first few portions:1, Qtum Core BrandingBasic Qtum Branding
Basic renaming of the Bitcoin code to make it into Qtum. This shouldn't be too extensive, but should cover the following:
1. Use ~/.qtum instead of ~/.bitcoin for data directory by default
2. Build system should output qtumd instead of bitcoind/cli etc
2, The Basic Qtum NetworkCreate basic Qtum network
Change the parameters so that the Qtum network is different from Bitcoin.
1. Change genesis seed
2. Change P2P/RPC ports
3. Change "magic" P2P network bytes.
4. Add whatever changes are needed so that a new mainnet network can be mined and synced.
5. Remove bitcoin checkpoints and node lists
6. Make sure that all 3 networks work: mainnet, testnet, and regtest. With mainnet and testnet being distinctly different and incompatible with Bitcoin
Make sure to remove irrelevant tests that only affect Bitcoin, and to change tests which rely on network parameters
specific params:
Block time: 128 seconds
Block size: 2Mb
P2P port: 3888 (chosen arbitrarily, shouldn't have conflicts, but can be changed if needed)
RPC port: 3889
testnet P2P port: 13888
testnet RPC port: 13889
Qtum pubkeyhash address: 58 (Q)
Qtum p2sh address: 50 (M)
Qtum testnet p2pkh: 120 (q)
Qtum testnet p2sh: 110 (m)
3, Add EVM and OP_CREATE for Contract ExecutionAfter this, the EVM should be integrated and a very basic contract should be executable.
There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order:
1. VM version (currently 1 is EVM)
2. Gas price (not yet used, anything is valid)
3. Gas limit (not yet used, assume very high limit)
4. bytecode
For now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain)
When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb)
Note:
Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed)
Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though)
QTUM Address for new contracts
QTUmCORE-3. Test that qtum address is generated after contract creation. Before running the test make sure that:
Node started в regtest
Bitcoin tests passed
Test Steps
1. Create transaction TX_DEPLOYMENT in bitcoinlib-js, run decoderawtransaction.
2. Create transaction TX_ASSIGN_SC in bitcoinlib-js, run decoderawtransaction.
3. Create transaction TX_DEPLOYMENT in bitcoinlib-js, run sendrawtransaction.
3. Create transaction TX_ASSIGN_SC in bitcoinlib-js, run sendrawtransaction.
Expected Result
1. Transaction marked as deployment.
2. Transaction marked as assign.
3. Contract created (address and balance are displayed on the console).
4. Contract state changed (address and balance are displayed on the console).
4, Add PoS block verification and miningAfter this, the Qtum blockchain should be capable of verifying basic PoS v3 blocks, and the wallet should be able to mine these blocks similar to PoW blocks.
There is not a network rule as of yet for only allowing PoS blocks at this point, so the chain will accept either PoW and PoS blocks as valid. Both block types should use the same default bitcoin standard difficulty.
Thing to ensure:
1, stake modifier changes every block
2, Coinage does not change PoS values
3, No decentralized checkpoints (still in design)
4, Make sure that these statements remain true:
5, don't enforce tx fee as consensus rule
6, static pos reward (make it just 1 token for now, will change later)
7, stake modifier v2 - The purpose of stake modifier is to prevent a txout (coin) owner from computing future proof-of-stake generated by txout at the time of transaction confirmation. Verification of the block was changed, now you need only previous block, so all other blocks can be deleted and space saved (you need last 500 blocks to stake) pruning capabilities should be in future major release
8, compatibility with BIP66
9, only last 500 blocks are needed to verify proof of stake
10, No coin age, instead just a coin confirmation requirement (500 blocks is fine for now)
5, Add ability for contracts to call other deployed contractsContracts should be capable of calling other contracts using a new opcode, OP_CALL.
Arguments in push order:
version (32 bit integer)
gas price (64 bit integer)
gas limit (64 bit integer)
contract address (160 bits)
data (any length)
OP_CALL should ways return false for now.
OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes.
If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script.
The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.
Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM.
Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool.
These updates should give you an idea of what we are working on leading up to the June 28th release of the Test Network. Please see the Roadmap below for more information:
Please remember that we have an event in Shanghai on the 28th so please RSVP if you plan on attending:
