Popular Post mDuo13 Posted June 27, 2016 Popular Post Share Posted June 27, 2016 https://ripple.com/dev-blog/rippled-0-32-0-released/ Ripple is proud to announce the release of rippled version 0.32.0. This release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to the new version. Highlights of this release include: The transaction queue now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. This encourages liquidity for XRP since important transactions now have a more reliable way of getting into the ledger. For more information, see Queued Transactions in the Ripple Developer Portal. The server_info and server_state commands now include information on transaction cost multipliers. Customers who want to robustly submit transactions now have additional tools for accurately setting the fee based on changing network conditions. Furthermore, the fee command is now available to unprivileged users. For more information, see the rippled API Method Reference in the Ripple Developer Portal. There’s a new WebSocket implementation based on Beast. Use of this implementation is optional. A future version of rippled will make this WebSocket implementation the default, with the old implementation removed. Read the complete release notes in GitHub. Actions Required If you operate a rippled server, you should upgrade to version 0.32.0 for the best performance. If you have backend software which constructs and submits transactions to the Ripple network, you may need to adapt it to correctly use the network’s new transaction queue mechanism. Impact of Not Upgrading If you operate a rippled server but don’t upgrade to version 0.32.0, your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. For instruction on updating rippled on supported platforms, please see Updating rippled in the Ripple Developer Center. The md5sum for the rpm is: 1b37fd80fd869e42a715f17a9e30c81a. The md5sum for the source rpm is: d43f4d371416b213d6197fb1c630cf44. For other platforms, please compile version 0.32.0 from source. See rippled Build Instructions in the Ripple Wiki for details. The first log entry should be the change setting the version: commit d22eb0caa25ecfbd373cc9af0347e56031a23646 Author: seelabs <scott.determan@yahoo.com> Date: Fri Jun 24 11:30:09 2016 -0400 Set version to 0.32.0 Network Update The Ripple operations team plans to deploy version 0.32.0 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Wednesday, 2016-06-29. The deployment is expected to complete within 4 hours. Learn, ask questions, and discuss Ripple supported documentation including detailed example API calls and web tools for API testing are located on the Ripple Developer Portal: https://ripple.com/build/ Other Resources: Ripple Official Forum: https://forum.ripple.com/ Ripple Dev Blog: https://ripple.com/category/dev-blog/ Ripple Technical Services: support@ripple.com XRPChat (This forum) yxxyun, Ant, nikb and 15 others 18 Link to comment Share on other sites More sharing options...
karlos Posted June 27, 2016 Share Posted June 27, 2016 Nice, looks like it went through a lot of beta versions. No recursive calls in the code, I assume? Hodor 1 Link to comment Share on other sites More sharing options...
T8493 Posted June 27, 2016 Share Posted June 27, 2016 5 minutes ago, karlos said: Nice, looks like it went through a lot of beta versions. No recursive calls in the code, I assume? Hidden dao? karlos 1 Link to comment Share on other sites More sharing options...
Apollo Posted June 28, 2016 Share Posted June 28, 2016 Very Cool!!! Well Done guy!!! Link to comment Share on other sites More sharing options...
nikb Posted June 28, 2016 Share Posted June 28, 2016 5 hours ago, karlos said: Nice, looks like it went through a lot of beta versions. Yeah, there was a lot of work put in 0.32.0 – and more cool stuff is coming! karlos, ltrading and Apollo 3 Link to comment Share on other sites More sharing options...
Morty Posted June 28, 2016 Share Posted June 28, 2016 51 minutes ago, nikb said: Yeah, there was a lot of work put in 0.32.0 – and more cool stuff is coming! Can you tell us anything about this cool stuff? Link to comment Share on other sites More sharing options...
T8493 Posted June 28, 2016 Share Posted June 28, 2016 53 minutes ago, nikb said: and more cool stuff is coming! Ripple DAO? Link to comment Share on other sites More sharing options...
tulo Posted June 28, 2016 Share Posted June 28, 2016 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 More sharing options...
RafOlP Posted June 28, 2016 Share Posted June 28, 2016 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. nikb and mDuo13 2 Link to comment Share on other sites More sharing options...
tulo Posted June 28, 2016 Share Posted June 28, 2016 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 More sharing options...
RafOlP Posted June 28, 2016 Share Posted June 28, 2016 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. tulo 1 Link to comment Share on other sites More sharing options...
tulo Posted June 28, 2016 Share Posted June 28, 2016 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 Link to comment Share on other sites More sharing options...
mDuo13 Posted June 28, 2016 Author Share Posted June 28, 2016 10 hours ago, Morty said: Can you tell us anything about this cool stuff? 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. MundoXRP, tulo, thinlyspread and 6 others 9 Link to comment Share on other sites More sharing options...
nikb Posted June 29, 2016 Share Posted June 29, 2016 On 6/27/2016 at 10:53 PM, Morty said: Can you tell us anything about this cool stuff? 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 Morty and MundoXRP 2 Link to comment Share on other sites More sharing options...
T8493 Posted June 29, 2016 Share Posted June 29, 2016 1 minute ago, nikb said: I am currently working on cryptocondition support for rippled. These cryptoconditions apply to transactions or to something else? Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now