rfc#0002 update state cost section

rfcs/0002-ckb/0002-ckb.md

@@ -60,7 +60,7 @@ The layered architecture separates state and computation, giving each layer more
 Possible state generation methods include (but are not limited to) the following:
 
 - Local generators on the client: Generators run directly on the client’s devices. Developers can implement the generator in any programming languages.
-- Web services: Users may use traditional web services to generate new states. All current web services may work with CKB in this way, to gain more trust and liquidity to the generated states. For example, game companies may define in-game props as assets in CKB, having the game itself function as a web service to generate game data which is verified and stored in CKB.
+- Web services: Users may use traditional web services to generate new states. All current web services may work with CKB in this way, to gain more trust and liquidity for the generated states. For example, game companies may define in-game props as assets in CKB, having the game itself function as a web service to generate game data which is verified and stored in CKB.
 - State channels: Two or more users may use peer to peer communication to generate new states.
 - Generation chains: A generation chain is a blockchain that generates new states and stores them in CKB. Generation chains may be permissionless blockchains or permissioned blockchains. In each generation chain, nodes reach the consensus in smaller scopes, which gives better privacy and performance. 
 
@@ -196,7 +196,9 @@ The CKB economic model is designed to motivate users, developers and node operat
 
 The creation and storage of states on the CKB incur costs. The creation of new states needs to be verified by full nodes, incurring computational cost; the storage of states needs full nodes to provide storage space on an ongoing basis. Current permissionless blockchains only charge one-time transaction fees, but they allow states to be stored on all full nodes, occupying storage space forever.
 
-In CKB, cells are basic storage units of states. Unoccupied cell capacity is transferable, and this gives cells liquidity. Users cannot transfer occupied cell capacity without first clear the state in it, thus lose liquidity on their occupied capacity. Therefore, cell owners pay for storage with the liquidity loss of cell capacity, which is an opportunity cost. The larger capacity and the longer time they occupy, the higher liquidity cost they pay. The advantage of pay by liquidity loss, compared to upfront payments, is that it avoids the problem that upfront payments could be used up, and the system would have to recycle the cells. Cells could have different owners and users, and owners can pay the liquidity cost on behalf of their users.
+In CKB, cells are basic storage units of states. Cell owner can use it to store state himself or lend it out to others. At any time, the same cell capacity can only be occupied by no more than one user. If an owner uses the capacity himself, it means he would give up the opportunity to earn interests by lending it out (either to CKB or other users), which incurs an opportunity cost to him. In this case, users pay for storage with a cost that is proportional to both space and time - the larger capacity and the longer time they occupy, the higher cost they pay. The advantage of CKB's implicit state cost model, comparing with upfront payment model such as storage rent discussed in Ethereum community, is that it avoids the problem that upfront payments could be used up, and the system would have to recycle the state and break any applications or contracts depend on it.
+
+Cell metadata (`capacity`, `type` and `lock`) are states, so they occupy users' cell capacity and incur state cost as well. This meta cost would incentivize users to create as fewer cells as possible to increase capacity efficiency.
 
 ### 5.2 Computation Cost and Transaction Fee