Jump to content

rippled 0.32.0 released


mDuo13

Recommended Posts

10 hours ago, mDuo13 said:

Highlights of this release include:

  • The transaction queue now supports batching and can hold up to 10 transactions per account,

 

Don't you think this is a huge limitation for BIG players?

Don't you think ~2.5 tps is too low for a bank or a very active partner? 

On the other side one can create multiple accounts but it is not very practical and requires extra work to synchronize multiple accounts for a single application.

Link to comment
Share on other sites

3 hours ago, tulo said:

Don't you think this is a huge limitation for BIG players?

Don't you think ~2.5 tps is too low for a bank or a very active partner? 

On the other side one can create multiple accounts but it is not very practical and requires extra work to synchronize multiple accounts for a single application.

The batching is only for transactions left out of consensus rounds (e.g. those who were created with an insufficient fee). If the bank creates healthy transactions (with reasonable fees) they will probably get 100% of txs included in the consensus round.

If I got it right, it means that now one account can have up to 10 txs in the queue waiting for the fees to lower a little.

Link to comment
Share on other sites

47 minutes ago, RafOlP said:

The batching is only for transactions left out of consensus rounds (e.g. those who were created with an insufficient fee). If the bank creates healthy transactions (with reasonable fees) they will probably get 100% of txs included in the consensus round.

Quote

When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. 

When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the un-scaled cost of those transactions.

It seems all the transactions goes into the queue...so it's 10 transactions per account per ledger-->~2.5 TPS.

And time to write a frontrunner bot ;)

 

Link to comment
Share on other sites

11 minutes ago, tulo said:

When rippled receives a transaction that meet the server's local load cost but not the open ledger cost, the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network.

No, you are misreading it. See that all transactions that meet the open ledger cost are not put in the queue, they are all processed. :)

Link to comment
Share on other sites

23 minutes ago, RafOlP said:

No, you are misreading it. See that all transactions that meet the open ledger cost are not put in the queue, they are all processed. :)

You're right :D

Link to comment
Share on other sites

10 hours ago, Morty said:

Can you tell us anything about this cool stuff? :D

I can!

A couple bits of code in this release are just preparing for bigger stuff down the line. For one thing, there's a new payment processing engine that's fully functional but not turned on yet. The new engine is better organized, and should also fix many small bugs in the way payments are processed (for example, charging transfer fees differently from how offers charge them, I think).

The new websocket code is way better (the old code has a lot of potential crash bugs we have to work around) and we think it'll probably get faster, too. (Right now, it's not optimized much for speed.) So when that gets turned on by default in a future release, it'll potentially speed up both development and the APIs.

Obviously suspended payments (SusPay) are still in the works -- we're iterating internally on ways to do more with them and faster. And there are "Tickets" which are a way to set aside a sequence number for a later transaction to consume. No particular deadline/roadmap on these of course.

But, in short, development is full steam ahead.

Link to comment
Share on other sites

On 6/27/2016 at 10:53 PM, Morty said:

Can you tell us anything about this cool stuff? :D

I sure can! From https://ripple.com/insights/avoid-another-bank-hack-distributed-financial-technology/:

Quote

Ripple will also offer a similar multi-sign capability in its solution for banks that implement the Interledger Protocol (ILP). This functionality, enabled by what’s known as crypto-conditions, allows banks to require customers’ cryptographic signatures on transactions so individual bank employees can’t transfer customer funds on their own.

I am currently working on cryptocondition support for rippled. The first step is implementing cryptoconditions in C++ and then integrating them into rippled.You can find the spec for cryptoconditions here: https://interledger.org/five-bells-condition/spec.html

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...