Bitccoin and nearly every other derivative (btishares included) uses an amortized consensus; the network of block producers gradually comes to an consensus on the transactions in a given block - they do this by building other blocks on top of the previous one, thereby adding a confirmation. This is why you need to wait for multiple confirmations before processing a transaction, because otherwise you only rely on the opinion of one entity, instead of the majority of the network.
Ripple, however, uses a non amortized (there is probably a better word) consensus, in that all the block signers actually work simultaneously on the current block in production. This means you get an entire network's worth of consensus on new transactions as soon as the block is produced.
DPOS could achieve the same thing if all witnesses sent their signature for the previous block to the next witness that is supposed to produce a block. That witness would collect all the signatures and include it in the block. If a large enough quorum (e.g. 80% to be consistent with Ripple) of active witnesses signed off on a particular block, then that is essentially the same thing as a ledger close in Ripple. This means in practice a block could usually be considered valid by a super majority of the active delegates in 2 seconds (two blocks with 1 second intervals).
If you want to avoid bloating each block with extra signatures from 80% of active witnesses you can use threshold signatures instead (as I have proposed here
). You can increase the delay from 1 block to some other small number of blocks to give the witnesses enough time to coordinate the threshold signature generation. For example, instead of this threshold signature signing the previous block it could sign for the block that is 3 blocks in the past. In that case a block could be considered valid by a super majority of the active delegates in 5 seconds. However, for the threshold signature generation to be simple and fast, ECDSA and secp256k1 aren't going to cut it. We would need to use EdDSA
which is a variant of Schnorr signature based on Twisted Edwards curve. The NaCl library
seems to be a good implementation of this digital signature scheme for regular signatures, but it would need to be modified (see this paper
for the cryptography necessary) to support threshold signature generation. Of course if that code was created and integrated into BitShares, many other users (particularly businesses who want to hide their authentication organizational structure from the public) could also take advantage of threshold signatures. Plus there are lots of other benefits
to using EdDSA as well.