Author Topic: DevShares ideas to consider before launch  (Read 9389 times)

0 Members and 1 Guest are viewing this topic.

Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
DevShares will launch this week.  A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast. 


Why do AGS+PTS get 33%?  Isn't 10% the 'social contract'?

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).

The problem with this approach is that the client needs a way to authenticate the delegates who sign that snapshot. But the votes authorizing the delegates are part of the snapshot, i. e. you have a circular validation process without a solid anchor.

The problem you are describing only applies to the lightweight client validation benefit that I was describing. And indeed as I mentioned those clients do need a way to verify the set of active delegates who can sign the snapshot to break that circular loop:
If a user's client was also able to be confident of the current set of active delegates (there are ways this could be done cheaply on a lightweight client with very minimal trust), then the lightweight client could with very minimal trust verify the existence of funds owned by the user as of a time as recent as the latest snapshot timestamp.
I will describe that process in a moment.

But for a full client, they already have the entire up-to-date database will all of the delegate approval vote changes. The full clients know at any block who the 101 active delegates are through the same mechanism as they currently do. And so they know to treat the blocks where these 101 active delegates sign a valid database snapshot hash as a legitimate block.

Now consider a full client that is trying to bootstrap to the present state of the database starting with a copy of the database as of block N1, the portion of the blockchain from block N1 to the present, and a checkpoint in the client of a block M more recent than block N1 (M > N1). The client does not know whether to trust the database copy the blockchain receives from the network. But it is able to calculate its hash. It first assumes this is the right database for the sake of evolving the database state into the future, and then it will later verify if it was indeed correct. The blockchain also does not know if blocks N1 to (M-1) are legitimate, but the checkpoint does verify the validity of block M. Because of the hash link, this also necessarily validates blocks N1 to (M-1). The client can then process blocks N1 to M by evolving the state of the database. At some point during this evolution, the client reaches block N2. It is then able to see that the active delegates at that time validated the hash of the database that the client started with. While the active delegates at the point of block N2 are dependent on the starting state of the database as of block N1, the client knows the active delegates are the real active delegates because otherwise the checkpoint would not match. If the starting state of the database was modified to change even one active delegate, their block signatures would be different and therefore the checkpoint of block M would be different. Because the client knows the active delegates and because our security model already assumes the delegates will not double sign, the client can know that further evolution from block M to the present can be trusted as usual. So even if N2 > M, the client can still reach block N2 in a trust-free manner and verify that the starting database it received was in fact valid. Further evolution beyond that as usual can allow the client to reach the present state.


The above still provides the benefits of pruning the legacy code from the client over time and speeding up the process of restoring the database from scratch for full clients. But what about the added benefits I described for lightweight client validation? Lightweight clients cannot be expected to scan through the blockchain, even a recent portion of it. Therefore they cannot find out how the delegate votes evolve and thus who the active delegates are without some other added mechanism. It is important to clarify that if the lightweight client doesn't know who the active delegates should be during the several blocks leading up to block N2, then the lightweight client doesn't have any way to verify the proof that the hash of the database as of block N1 is indeed the correct one. Anyone could sign a hash of a fake database with 101 signatures claiming they were the active delegates. If the lightweight client believed that those were the set of active delegates, the attacker could supply the lightweight client with a database proof saying anything it wanted (such as the false existence of some balances in the victim's control in order to pull off a double spend).

To deal with this issue, the lightweight client would need some way of knowing the set of active delegates at any block. We could require that the hash of the ordered set of current active delegates could be included as part of the digest that the delegates must sign in every block in order for the block to be valid. A lightweight client could then download the block header of block M which it knows is valid because of the checkpoint in the client. This block header immediately proves to the client whether a given set of active delegates as of block M is correct. Then using only the small block headers, it could evolve this set of active delegates into the future. It can know which delegates are supposed to sign which blocks (using the active set and random numbers in block headers) and it can verify that the block headers it receives are properly signed by the intended delegate. In order for an attacker to supply fake block headers beyond block M that change the active set of delegates to a false one, it would require at least 51 delegates in one of the rounds to collude together to double sign fake blocks (which would by the way act as proof to get them fired, assuming they haven't been already). But that already breaks the security assumption that we hold in DPOS, so it is reasonable to assume this will not happen as long as the checkpoint block M is not too far in the past (not, for example, older than 6 months). The lightweight client can of course store an up-to-date copy of a checkpoint (derived from the evolution of block headers), so that it can resume this process whenever it wants to find the more recent set of active delegates. It would also store the database hash of the most recent verified database snapshot (which it is able to verify is the correct one because it checked the validation signatures of the active delegates at the time). With this information kept up-to-date, the lightweight client can then easily verify provided proofs of the existence of some (key, value) tuple in a recent database snapshot.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).

The problem with this approach is that the client needs a way to authenticate the delegates who sign that snapshot. But the votes authorizing the delegates are part of the snapshot, i. e. you have a circular validation process without a solid anchor.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
     Value backed by inflationary BitShares.  My original proposal had a promise to issue inflationary BitShares to the terminal snapshot with a BitShares hardfork.  For a variety of reasons, I no longer think that is workable.  Perhaps we could simply have a 100% BitShares delegate who promises to run both BitShares and DevShares clients and issues regular distributions to DevShares balances according to some algorithm?
I like this , DevShares is in Bitshares client. the different is using different regular to sign tx. create block . eg. 
and I also don`t understand why we need a new chain. how attract people to join new chain
BM can you give more reason?
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
- A terminal block as well as genesis block.  In other words, clients are pre-programmed from Day 1 to halt on a fixed date/time.  The plan is to take a snapshot of the final state and to initialize a new genesis block, and/or hardfork(s) which postpone the halt date.  The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).

This brings up something that I really want to see in BitShares eventually, even though it is a significant restructuring of how the system works. I would love it if there was a process running in parallel that continuously takes snapshots of the essential subset of the client database in such a way that the entire database can be represented in a platform-agnostic way by a single hash and the memory and processing bounds for the proof of a particular (key, value) pair existing in the database is O(log(N)) where N is the number of unique keys in the database.

When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).

Now say a client wants to synchronize with the network. Instead of starting from the genesis state, it can instead download a copy of the database snapshot as of block N1 as well as the blockchain from block N1 to the present. The client would also need a checkpoint of a block greater than or equal to N1. It can then update the database it downloaded from its state as of block N1 to its present state by only processing the part of the blockchain from block N1 to the present block. This also means that all legacy code that was necessary to process the blockchain prior to block N1 would no longer be necessary in this client (legacy code for understanding how to handle old database entries would still be needed however).

There is an added benefit if the snapshot process is fast and the memory and processing bounds for proofs I mentioned above hold true. Someone with a full client could construct a manageable-sized proof showing that a requested balance exists in the database as of a particular timestamp with a certain value and which can be withdrawn by certain addresses. The timestamp would have to be at the snapshot boundaries. If a user's client was also able to be confident of the current set of active delegates (there are ways this could be done cheaply on a lightweight client with very minimal trust), then the lightweight client could with very minimal trust verify the existence of funds owned by the user as of a time as recent as the latest snapshot timestamp. I would hope that properly optimized code could make this snapshot process regularly occur with a time period of 30 minutes or less to make this verification practical for the lightweight client user.

Offline theoreticalbts

The same as Sparkle one?

Toast is working on the blockchain state dump right now.  Perhaps he could give us a block number?
the delegate formerly known as drltc

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?

December 14.

The same as Sparkle one?
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline theoreticalbts

Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?

December 14.
the delegate formerly known as drltc

sumantso

  • Guest
DevShares will launch this week.  A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast. 
+5%

Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?

Hope not, the exchanges didn't take any snapshot.

Maybe use the PLAY snapshot?

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
DevShares will launch this week.  A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast. 
+5%

Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline bytemaster

DevShares will launch this week.  A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast. 

DevShares will be identical to BitShares with the only difference being the "effective block number" of hard forks.  In this way we can be sure that the problems experienced by the BitShares network this past week happen on DevShares and BitShares can enjoy a nice smooth upgrade cycle.

中文翻译:
DevShares将会在本周发布.  Toast正在准备快照给AGS/PTS/BTS各33/33/33.
DevShares将会等同于比特股, 唯一的差别就是硬分岔的'有效区块数'.  这样一来就可以确定如果比特股网络出现像是过去一周的问题, 那么DevShares也会出现, 因此将来比特股可以有比较平顺的升级周期.
« Last Edit: December 18, 2014, 01:40:01 am by cn-members »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Devshares!  +5%  Will it come before Christmas?
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline theoreticalbts

We're working on implementing DevShares in the near future.  My original proposal for DevShares (under my old account, drltc) had the following two features.  AFAIK these are not currently slated for inclusion in DevShares, but I wanted to bring them up before launch:

 - A terminal block as well as genesis block.  In other words, clients are pre-programmed from Day 1 to halt on a fixed date/time.  The plan is to take a snapshot of the final state and to initialize a new genesis block, and/or hardfork(s) which postpone the halt date.  The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).

- Value backed by inflationary BitShares.  My original proposal had a promise to issue inflationary BitShares to the terminal snapshot with a BitShares hardfork.  For a variety of reasons, I no longer think that is workable.  Perhaps we could simply have a 100% BitShares delegate who promises to run both BitShares and DevShares clients and issues regular distributions to DevShares balances according to some algorithm?
« Last Edit: December 22, 2014, 09:39:28 am by cass »
the delegate formerly known as drltc