CKB Developer AMA #1 with Tannr – Nervos Network
Q: Can you explain the Nervos DAO?
In *Nervos DAO* there is the concept of a “deposit period” that lasts 180 epochs. If you deposit CKBytes into the DAO and create transactions to withdraw them before 180 subsequent epochs, then at the end of that deposit period is when the CKBytes are withdrawn.For more info on how to deposit and withdraw, check out our RFC about the nervos DAO here: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md
Q: 1.344 billion tokens per year is the total inflation?
It is the total inflation from secondary issuance
Q: If 1.344 billion tokens / year is the total inflation? Or there’s additional inflation through nervos dao?
It’s the total inflation from secondary issuance. The Nervos DAO does not provide additional inflation, rather it distributes a portion of secondary issuance to addresses with tokens locked in DAO. Tokens are also created via block rewards for miners
Q: The Nervos Foundation will write data to occupy 15% of the CKBytes in the genesis block, while leaving the other 10% CKBytes of the genesis block liquid (not being locked into NervosDAO!)” — who holds the private keys for these tokens? Are they provably “frozen” and “immovable”
You can view the lock scripts on the cells created during genesis to verify that the system cells and the burned tokens use the right lock script See here: https://explorer.nervos.org/block/0x92b197aa1fba0f63633922c61c92375c9c074a93e85963554f5499fe1450d0e5
And then the first tx within that block: https://explorer.nervos.org/transaction/0xe2fb199810d49a4d8beec56718ba2593b665db9d52299a0f9e6e75416d73ff5c
You can also look in the ckb repo under resource/specs/mainnet.toml to see this
Q: How to construct cell_deps and header_deps in the transaction body, is it unchanged?
This depends on the SDK you’re using, but essentially, deps are outpoints. To include a dep in the transaction, you have to have the outpoint of the cell you’re wishing to include, which means that cell should already exist on-chain.
Q: The transaction said “InvalidCodeHash” what does this mean?
The “invalidCodeHash” error message signifies that there is a problem with one of the script’s references on one of the cells in your transaction. Remember that cells have an optional type field and a required lock field. Both of these fields contain a JSON-like object containing reference information to executable code stored in some other cell on-chain. When a transaction is being processed, all dependencies are loaded. When inputs and outputs in the transaction are being processed, part of this procedure involves loading and executing the scripts referenced by the type and lock fields. The codeHash in the JSON-like script structure refers the hash of a dep cell’s (i.e., a cell referenced in the transaction’s dep field) type field or its data field. If the hash is formatted incorrectly or the dep cell w/ the corresponding codeHash is not included in the deps field, you will experience errors.
Q: How many CKBytes will I earn from locking in Nervos DAO?
The CKBytes you will receive is proportional to the increase of total supply caused by secondary issuance. So, if you locked your tokens for a year and secondary issuance increases total supply by 4%, then your supply will increase by 4% as well. The initial supply from genesis is 33.6B CKBytes and secondary issuance occurs at a constant annual rate of 1.344B CKBytes. The APC from genesis to end of first year would be 3.7% then. See the Nervos DAO RFCs and calculations for more details: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md
Q: Any articles about stateful apps in cells? in the CKB model, does any confirmed tx reading a cell kill the cell?
We are working on creating more educational content for the community, as well as building more tools to make development as easy as possible. We do have some good content on the cell model already, which you can find in our RFCs repo. We also have discussions about development on our forums (https://www.talk.nervos.org). If a cell is used as an input, it is destroyed. However, transactions have a deps field as well, which allows you to include cells as dependencies that can be accessed by scripts in the transaction without destroying the cell.
Q: Is there any testing infra for CKB scripts?
Here is a prototype of a debugger for CKB scripts. We are working hard on creating more, and better, tooling for CKB development and welcome the community to participate in these endeavors. After all, it is a decentralized network! You can find the debugger repo in the Nervos Network github. One of our developers, Xuejie, who co-developed the CKB-VM has written a great article explaining how to use this debugger: https://xuejie.space/2019_10_18_introduction_to_ckb_script_programming_debugging/
Q: Can a cell be an input and output of the same transaction? if so you can communicate that way
A cell cannot be an input and output of the same transaction. A cell is referenced via an outpoint which contains the transaction hash of the transaction which created the cell as well as the index of the target cell in the outputs of the transaction. Despite this, CKB’s programming model is extremely flexible and there are multiple ways a person could achieve inter-cell communication.
Q: How many bytes is a CKB balance?
A: 1 CKByte represents 1 Byte of capacity for a cell. The internal denomination of CKBytes is measured in “shannons”, where 1 CKByte equals 10 ^ 8 shannons.
Q: What’s the point of clients computing new state if (a) block producer has to re-compute it and (b) the data is fully on-chain?
A block producer does not have to compute new state. Nodes execute verification scripts to validate state changes, and these scripts can use whichever algorithm(s) the developer has chosen. If I am building a collectible card game with NFTs, for example, I may want to build auction capabilities and an entire marketplace for this. This can all be built off-chain. Only the crucial data must be stored on-chain. For example, ownership of some card. So, all of this sophisticated computation can be performed off-chain, with only the final settlement of the new owner being submitted on-chain.
Q: The verification/generation decoupling .. what’s the benefit if both clients and nodes have to perform computation?
The purpose of decoupling generation and verification is that it allows people to better leverage the properties of a layer 1 blockchain with high security & decentralization. It is not that CKB separates computation and verification, since verification scripts are technically a type of computation. Rather, on-chain scripts do not produce further state-changes; they merely verify state changes. This has multiple benefits. First, this makes the programming model simpler and easier to reason about. The result of the state-change is known ahead of time because script execution does not produce potentially unpredictable side-effects that need to be accounted for. Second, it would be a waste of resources to place the responsibility of generation on-chain: the purpose of a layer 1 high security, high decentralization blockchain is to provide strong guarantees about the truth and validity of on-chain data. In short, state generation doesn’t need to be decentralized if the verification is decentralized because the verification provides those guarantees, not the generation. We see an evolution over the past few years where there has become a natural division between layer 1 and layer 2 projects. Layer 2 projects are extremely diverse. By leaving state-generation off of the chain, we avoid confining the ways in which state needs to be generated, opening the possibilities and flexibility afforded to layer 2 projects that wish to use CKB for settlement and verification.
Q: Does a verifier do the same amount of work as a generator ?
Since generators are responsible for generating a state change via packaging it as a transaction and submitting it to the CKB, they will perform some computation to create that state-change and to verify that state change (why submit a tx that is invalid in the first place, incurring unnecessary costs?). The verification logic that operates on-chain can use a more optimized algorithm and/or implementation of that algorithm. In general, generators should perform more computational work than verifiers, since verification occurs on-chain where the resources are more limited o that end, greater work on-chain means greater fees and there are limits to transaction size as well as computation that can occur for the scripts executing as a result of transaction verification. The verification rules are up to the developer here. But the generators will probably perform a lot more work to ensure that only correct state (at least most of the time) is ever submitted
Q: Can we simulate a cell using an Ethereum contract?
That’d be very difficult depending on what exactly you want to simulate. A cell is just a data structure. But could store a cell set in a contract or a set of contracts. In CKB, cells data field can contain executable binary code. In Ethereum, executable code is limited to EVM bytecode, whereas CKB is built with a RISC-V VM. So, you could create something that looks like a cell on Ethereum, but it’d be extremely difficult to get them to behave correctly. It probably could be done, but the result would most likely be something nearly useless.
For more reasons than just the VM side of things, though. You could build a RISC-V VM with an EVM compatible language, then you could build cells on it, associating one cell per contract.. etc., etc.,.. Like I said, the result would be something pretty messy
Published at Wed, 18 Dec 2019 00:56:19 +0000
{flickr|100|campaign}
