Author Topic: Sub-second confirmation time with full and lightweight clients?  (Read 2468 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
delegates are simply nodes on the p2p network .. they just broadcast signed blocks to the network ..
If you did a timing analysis and where connected to a delegate you could figure out which of you connections is a delegate (or at least closer to a delegate in terms of hops)  ...

for the delegates it seems to be a good idea to span a two Tier system where the tier-0 is the delegate and only connected to tier-1 nodes which are heavily connected to the network .. just to 'hide' the real IP of the delegate .. (this will for sure come)

Offline testz


IMHO You will understand it's better if think about delegate as Bitcoin miners (today it's a pools) and seed nodes as bitcoin full nodes. Blocks propagates more or less in the same way as in Bitcoin.

I do already think of the delegates as analogous to Bitcoin mining pools. But Bitcoin mining pool operators can be DDOSed, so what is to stop DDOSing delegates as things are set up right now? If the worry with my proposal is about the multiplicative factor (51x) of packets sent to delegate's servers, then the IP addresses that are broadcast can be the delegate's proxy instead which would first check to see whether the transaction is valid (with appropriate fee) before propagating it to the intended 51 delegates' servers and waiting for their signature responses.

Bitcoin miners pools can be DDOSed only because they should accept shares from actual miners, but if they will mine alone (as it's was at beginning)?

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
IMHO You will understand it's better if think about delegate as Bitcoin miners (today it's a pools) and seed nodes as bitcoin full nodes. Blocks propagates more or less in the same way as in Bitcoin.

I do already think of the delegates as analogous to Bitcoin mining pools. But Bitcoin mining pool operators can be DDOSed, so what is to stop DDOSing delegates as things are set up right now? If the worry with my proposal is about the multiplicative factor (51x) of packets sent to delegate's servers, then the IP addresses that are broadcast can be the delegate's proxy instead which would first check to see whether the transaction is valid (with appropriate fee) before propagating it to the intended 51 delegates' servers and waiting for their signature responses.

Offline testz

And then you can DDOS the whole network by DDOSing 101 publicly known addresses ..

Good point. I'm ignorant about how the network currently works. Is it impossible to find the delegate's IP addresses in the current system? How do transactions propagate to delegates and how do delegates propagate their signed blocks back without leaking their IP addresses to the public?

IMHO You will understand it's better if think about delegate as Bitcoin miners (today it's a pools) and seed nodes as bitcoin full nodes. Blocks propagates more or less in the same way as in Bitcoin.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
And then you can DDOS the whole network by DDOSing 101 publicly known addresses ..

Good point. I'm ignorant about how the network currently works. Is it impossible to find the delegate's IP addresses in the current system? How do transactions propagate to delegates and how do delegates propagate their signed blocks back without leaking their IP addresses to the public? 

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
And then you can DDOS the whole network by DDOSing 101 publicly known addresses ..

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Nice thoughts... but
Quote
and send it to next 51 delegates

The IP addressses of the delegates are not known to the network ..?

I don't see why it can't be. Active delegates could sign statements that tell the public their recent IP address with some expiration time. Seed nodes can have these statements floating around on the network available for any client to download. Once a client has an IP address of a delegate it knows is active (from the blockchain or blockchain headers), the client can attempt to connect to the IP address with a secure encrypted connection and verify that the connection is with the expected delegate by verifying the proof the other party provides using the known public key of the delegate's account. So, there is no need to trust anyone whether the IP address is valid or not; a client will know if it is connected to the delegate.

I was thinking instead of a client simultaneously connecting to all 51 delegates, the client would instead just open a single TCP connection to one of the active delegates. Then, the client could make a request for signatures of approval of a given transaction from the 51 specific delegates, which the proxy delegate would forward to the desired delegates (on their already established private delegate network), collect the responses, and forward them back to the client over the single TCP connection as the signatures come in.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Nice thoughts... but
Quote
and send it to next 51 delegates

The IP addressses of the delegates are not known to the network ..?

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
 +5% Interesting optimization. Bytemaster is going to have to address this.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
In DPOS, blocks are produced in 10 seconds and thus we say the recommended confirmation time is 10 seconds. In reality, since blocks can be missed, the only way of being sure your transaction is in the consensus chain is if the block it is in has been approved by more than 50% of active delegates. By approved, I mean an active delegate signed a block that either contained the transaction or built the chain off a block which contained the transaction. Thus, the worst case confirmation time is actually around 8.5 minutes (actually I would say the true worst case confirmation time theoretically could be unbounded since delegate participation rate could be <50% for an indeterminate number of rounds). But in realistic scenarios, blocks are rarely missed and so one should not expect to wait more than 10 seconds to have their transaction confirmed with a high degree of probability.

So what I was thinking was that with just a little alteration to the protocol, we could get the recommended confirmation time below 1 second (I think, depends on network conditions). The idea is to take every transaction a user wants to broadcast (such as the signed transaction sent by a customer to a merchant) and send it to next 51 delegates (in block signing order) so that each of them can make sure the transaction is valid and send back signatures that claim that they will approve that transaction by their next block (this means include the transaction in the block unless it is already included in a previous block in the chain the delegate is building off of). They also keep that transaction in their working memory so that any new transaction received that would invalidate the prior transaction is considered invalid (a double-spend). If a delegate signs a block which doesn't approve the transaction they said they would approve by that block, the user can submit the signature to the network as proof that the delegate lied and get the delegate automatically fired. The reassurance that delegates will eventually lose their job if they break their promise to approve the transaction should be enough for the user to assume the transaction will go through. This means that as soon as all 51 of those delegates return their signatures for that transaction, the user can consider that transaction to be included in the chain even if it won't actually happen until a little later. Since, delegates are going to be online and responsive most of the time, it is unlikely that there will be a delegate in that group of 51 that does not respond extremely quickly. However, if it is the case that one of the delegates is not responding quickly or at all, then the user can just wait longer (usually 10 seconds but up to 8.5 minutes) to get confirmation of the transaction being included in the blockchain.

The other benefit of this approach is that it can be used with lightweight clients. As long as the lightweight clients are able to know who the current active delegates are (more on that later) and their ordering (just put the delegate's random number can be kept in the block header), then the signatures they get back from the 51 delegates should be enough assurance to the user that they actually received the assets they expected to receive. If the user later goes on the full client on their PC and finds out the transaction was never approved, they now can submit proof to get those delegates fired.

The lightweight clients need to know who are the active delegates in a given round. I think the way to make this work is to require the delegates to include the delta updates on the set of top 101 delegates in each block header. If the votes in the block causes delegate A at slot 101 to be replaced by delegate B, the block header for that block should note that A is out and B is in. Obviously all full clients on the network would require the block header deltas to be consistent with the vote changes in the block, or else the block would be invalid. Lightweight clients can rely on there being enough full clients online monitoring the full blocks and voting out any delegates that lie about the block headers. Under that assumption, the lightweight clients only need the block headers to keep the set of active delegates up-to-date over time.

I would also make sure to include in the block header two different Merkel tree roots. The first Merkel tree would have all the transactions in the block in a well-specified order as its leaf nodes. The second Merkel tree would have hashes corresponding to each trading asset pair in the decentralized exchange as its leaf nodes (again in a well-specified order). These hashes would be determined by taking the hash of the list of all transactions (in a well-specified order) defining all of the open market orders (up to that block) for the particular asset pair exchange market. With these two Merkel tree roots in the block headers, any full nodes (not just delegates) could provide Merkel branches to prove the existence of any transaction in the blockchain and prove to the lightweight clients that the client has received all open market orders (up to some block) for a given exchange market. This way lightweight clients could get accurate up-to-date information on the decentralized exchanges and get proof of any unsolicited funds sent to them more than 10 seconds ago (really more than 8.5 minutes ago to be safe), and all without having to burden the delegates to sign any statements. The lightweight (and full) clients would only burden the delegates for signatures for transactions that are sent from one party to another in a "real-time" environment (point-of-sale transactions) where sub-second confirmation times are desired.