Viewing 5 reply threads
  • Author
    • #14977

      Why is there a need for a centralized bundler?

      There can be only one bundle per chain per block. Every business that wants to run a personal bundler must compete with every other business’ bundler, so if there are many simultaneous personal bundlers there may be unavoidable long delays. Each personal bundler must also compete with other transactions. As the Ardor platform becomes more congested with general transactions then there may be no empty blocks and personal bundlers may become impossible or too expensive to be practical.

      Another problem is that bundlers may advertise rates that are too low and then become inactive leaving transactions that will expire before being confirmed.

      This service offers a way to combine many personal bundlers so that these transactions don’t need to compete with each other as they will typically be confirmed together and so applications built on the Ardor platform will have a way to minimize blockchain confirmation latency for their users.

      The fee payed will always be the lowest fee required by the blockchain. A transaction that requires 0.01 ARDR will only pay 0.01 ARDR. The transaction sender or contract does not need to guess a fee rate and does need to overpay to compensate for false rates. All users of the service can set a fee rate of zero for the transactions that are filtered by customizable rules.

      The service will also attempt to combine with general transactions so that many more transactions are confirmed without delay.
      By combining transactions in this way there will potentially be more blocks available for other personal bundlers that want to operate independently.

      How to get started?

      The first rule is created automatically and bundles all transactions sent from the account that sent the deposit. Making a deposit is the easiest way to use the service if all that is required is a personal bundler. This bundler can be made more powerful by adding new rules. Rules can be specific for an account or general such as all accounts that purchase goods or an asset. An account have have several rules at once.

      There is no service fee. 1 ARDR deposit will credit 1 ARDR worth of transaction fees. The deposit is divided into cents where 1 ARDR is equal to 100 cents. 1 cent is typically the lowest transaction fee such as an asset purchase or transfer. Deposits that contain a fraction of a cent are rounded down to the nearest cent so a deposit of 1.009 ARDR would credit 100 cents. It is possible to request a refund at any time and the refund transaction has a standard 1 ARDR transaction fee deducted from the balance.

      There is no permanent cost to creating new rules. Each new rule temporarily locks 10 cents while that rule is active. The locked tokens are returned after that rule expires or is deleted. Rules that exceeded limits or are ineffective are automatically removed and their locked funds are released so they can be used to pay for other rules or refunded.

      How to add or change rules?

      Rules are sent by encrypted message to @bAPI. A message can contain multiple commands. Each command should be separated by a newline. Messages are processed after at 1 confirmation.

      After sending a new rule or just to check the status of the active rules send a blank message to @bSTAT. The account will reply with the account balance and the active rules. To use this service or create any rules there must be a balance with the bundler. The deposit address is @bundlr. 0.01 ARDR credits 1 cent.

      Messages sent to @bSTAT should be blank and must be unconfirmed (zero fee) transactions. The reply will be an unconfirmed encrypted message. The reply is updated about every minute. There is no cost to query and a message can be sent any time.

      It is possible to set per user limits to prevent a single account draining a rule or account balance. Specific accounts can also be excluded from using an account’s rules.

      The commands are not case sensitive.

      rule filter set command creates a rule that is matched with unconfirmed transactions. id field is used to match assets, goods, currencies and polls. The type and subtype are numeric value for the transactions. chain is the numeric value of the chain for example Ignis is 2. * is used to match any value. If a rule does not require an id or recipient then * is used for those parameters. 0 is used for “phased” and the message parameters if they are not allowed. * is allowed and r if required.

      rule filter set sender type subtype chain id sum_limit transaction_limit user_limit phased message_prunable message encrypted_prunable encrypted message_self

      rule filter defaults command delete all rules and recreates the rule to bundle all the account’s transactions if missing. All locked balance is available for the rule’s use or for refund.

      rule filter defaults

      rule account limit command changes the limits for a specific user. These user limits and exceptions apply to all rules. user is the account ID in numeric or RS format. ? parameter will use the rule filter’s value.

      rule account limit user sum ? transaction_limit user_limit

      refund command will broadcast a refund of the unspent balance. 1 ARDR is subtracted as required to pay for the transaction. The account is deleted.

      refund * *

      Rule Examples

      Asset bundler:

      rule filter set * 2 1 * 12345 * 500 1 10 0 0 0 0 0 0
      rule filter set * 2 2 * 12345 * 500 1 35 0 0 0 0 0 0
      rule filter set * 2 3 * 12345 * 500 1 35 0 0 0 0 0 0

      This is an example of a set of rules that will include all buy (subtype 3), sell (subtype 2) and transfer (subtype 1) transactions for an asset (type 2) (id 12345) sent from any ‘*’ account but with anti-spam limits that prevent abuse by individual accounts. In this example there is a limit of 1 cent per transaction. New accounts would require an additional 100 cents for their first transaction. Also there is a limit of 35 cents per rule per each account which in this case would allow an account 35 each of buy and sell transactions from each rule. These rules don’t 0 allow transactions with any other attachments such as phasing or messages. Each of these rules have a hard limit of 500 cents lifetime spent.

      Goods purchase bundler:

      rule filter set * 3 4 2 67890 * 500 1 50 0 0 0 0 0 0

      This rule will bundle a goods (type 3) (id 67890) purchase (subtype 4) from any * account. The chain must be specific for goods transactions. It is set to 2 Ignis in this case. Phasing and message attachments are not allowed. The rule could be modified to allow new accounts to make purchases by setting a transaction_limit of 101. New account transactions will be enabled in a future Ardor release.

      User limit:

      rule account limit ARDOR-RMAP-225P-CQQP-22222 ? ? ? 50
      rule account limit 123456789 ? ? ? 50

      These rules allow per account exceptions to be made for higher or lower limits. An * character for a limit would allow an administrator account unlimited use up to each rule’s lifetime limit. A 0 would prevent that account’s transactions from being paid for by any of the setter’s rules. The two rules are equivalent and show alternative formats for account ids.

      rule account limit ARDOR-RMAP-225P-CQQP-22222 ? ? ? *
      rule account limit ARDOR-RMAP-225P-CQQP-22222 ? ? ? 0

      The first rule gives an account ARDOR-RMAP-225P-CQQP-22222 unlimited use of all rules but keeps ? the original transaction_limit of the rules.
      The second rules blocks the specific account from using any of the active rules by setting 0 for user_limit.


      refund * *

      This is the command to request a refund. If the account balance is greater than 1 ARDR the transaction will be broadcast and the account deleted. A balance of 1 ARDR or less won’t be refunded as this is below the minimum 1 ARDR transaction fee.

      How could the Ardor platform reduce the need for a centralized bundler or this service?

      The idea is identical to bundles. A transaction that envelops(bundles) an under-paying transaction in a fee which would provide a mechanism for personal bundlers to customize their sponsoring rules while at the same time avoid the need to compete with each other. Like the existing bundle transaction but instead it pays a chain fee. The envelope could include and pay for several transactions at once. The envelope would replace the plain transactions in the queue. This mechanism would also allow accounts to increase a transaction’s fee in response to competition for a place in the next block or to meet the minimum bundling rates but without needing to guess a fixed fee and so avoid overpaying.

      Bundler API account : @bAPI
      Reporting account : @bSTAT
      Deposit account : @bundlr

      • This topic was modified 3 weeks ago by bAPI.
      • This topic was modified 3 weeks ago by bAPI.
      • This topic was modified 3 weeks ago by bAPI.
      • This topic was modified 3 weeks ago by bAPI.
      • This topic was modified 2 weeks, 2 days ago by bAPI.
    • #14982

      Hi @bapi and welcome!
      I have to say that it’s very interesting. But I’m trying to imagine the possible scenarios.

      – Let’s say you have the bundlers as they are set today. If a bundler has enough “fee limit” then more transactions from multiple sources will be bundled by that same bundler as users will use the lowest available fee and therefore those transactions will be bundled by that specific bundler.
      – If more services want to use their own bundler, then I can see a benefit. Let’s assume that we have 10 services and all of them want to bundle their own transactions, then we have that possible queue that you mention. In this scenario, these services could use bAPI to that all possible slots of 100 tx x block can be used at the Ardor transaction cost.
      – If services have their own child-chain then those bundlers are separate and therefore would have their own queue as each ardor block can manage 100 tx x child-chain. So if you have congestion on Ignis, you might not have congestion in Bitswift.

      So this would be particularly useful for Ignis because that’s where most of the services in search of a public blockchain will most likely generate their transactions.
      Personally, if I think for example of smartvoting, there I don’t think I can use bAPI and the reason is that I need to set the account property bundler for those users I generate and during the generation of the voting I generate potentially thousands of transactions and I think it’s easier to bundle them myself instead of sending ardor to bAPI in order for bAPI to anyway fill the blocks with all smartvoting transactions.
      But definitely for services that don’t generate hundreds of transactions and for the sake of filling the blocks I can see some possible benefits.

      Thanks for sharing this!

    • #14984

      …and one legitimate question that will come for sure is:
      How are we sure that we send you Ardor and you don’t escape with them? 😉

    • #14986


      Thank you for the welcome and sharing your use case and insights.

      Paying a chain fee is always the best option if this is available.

      For the purpose of explaining a way in which the service can be used we will try apply the service to smartvoting. You say that accounts are marked with a property to know which account’s transactions to bundle? With bAPI this would be done with a rule for the transaction type and the account property would be replaced with a list of approved accounts each with limits to prevent abuse, if necessary.

      As an example the transaction type will be 9 for voting and subtype 1 vote-cast. The rule will allow any account to match but we will later limit it individually with per account rules.

      rule filter set sender type subtype chain id recipient sum_limit transaction_limit user_limit phased message_prunable message encrypted_prunable encrypted message_self

      rule filter set * 9 1 * poll_id * 5000 2 0 0 * 0 0 0 0

      This rule sets limits on how much total ARDR can be spent to 5000 cents or 50 ARDR and a per user limit of 0 cents. Setting per user_limit to 0 prevents the rule from activating. Later we will bypass this limit on a per account (user) basis, similar as you do with setting account properties. This rule allows a prunable message for example but the total transaction is limited to 2 cents unless also bypassed. Creating this rule will lock 10 cents if it is a new rule or 0 cents if the default rule is replaced. Next we create per account limits, there is no balance lock for account rules. To create these rules an encrypted prunable message is sent to @bAPI.

      rule account limit sender balance ? transaction_limit user_limit

      rule account limit account1 ? ? ? 4
      rule account limit account2 ? ? ? 4

      rule account limit account9 ? ? ? 4

      account1 is replaced with the account id in any format for each account that will be bundled. The user_limit is 4 which allows each account to spend 4 cents of the rule’s total which is 5000 cents in the example above. Only the accounts specified will be bundled and updating the rule is as simple as sending a single message containing the rule and account limits. There is a platform limit of about 42kb compressed data per transaction but a set of rules for thousands of accounts can be split between multiple messages if needed.

      The appeal of the service is the ease of setting up and changing the filters. Later all accounts can be updated with a * rule such as:

      rule account limit * 0 ? ? 8

      This command sets all known accounts to 0 balance spent and a new user_limit of 8 cents, which are limits that apply to all rules.

      On the question of what prevents us from escaping with user’s funds intentionally or by some misfortune? There is no guarantee that we can give. Maybe the notion of going to the trouble of creating a community service to steal some ARDR is sufficiently absurd but history has examples of people doing worse for less.

      Maybe a future development of the platform will provide a usable escrow but we don’t have any hope of such in the near future. Do you have any thoughts on this?

      If there is demand for this service we have some preparation to account for bundled transactions being isolated on forks and reliability of the service in general that should further improve the latency. With the lower confirmation times this need will become more apparent.

    • #14987

      Personally I find the service very interesting.
      Regarding the “escaping with the funds” I guess this might not be an issue once the users start using the service and trust the service.
      On the other hand to make the service completely trustless, and this is important in the blockchain space, I’m wondering if there is some way to add some technical guarantee in that sense.
      That would be the extra piece to assure the users that there is nothing to be concerned about. I’ll give it some thoughts and let you know if I come up with some idea.

    • #14990

      Any ideas on an escrow would be very welcome. We agree that this is an important issue and that this involves every user that wants to provide or use a service that must accept a down-payment in exchange for an uncertain future service.

      bAPI’s bundler needs direct access to the ARDR deposits to pay for the transaction bundling. If there was a mechanism that could return the unspent part of the deposit to the original sender after a specific period of inactivity that could solve the problem of a service losing access to deposits,

Viewing 5 reply threads
  • You must be logged in to reply to this topic.

©2020 Ardor Rocks


Log in with your credentials


Forgot your details?


Create Account