Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address slow fee estimation on Byron wallets #2128

Merged
merged 3 commits into from
Sep 9, 2020

Conversation

KtorZ
Copy link
Member

@KtorZ KtorZ commented Sep 9, 2020

Issue Number

#2126

Overview

  • fc1da51
    📍 extend post-restoration benchmark wallet overview with number of addresses and transactions
    We had only the UTxO, which gave little clarity about how many addresses and transactions did that correspond to. In practice, they're of the same order of magnitude, but it's good to have the actual number.

  • a234e49
    📍 do not construct dummy bootstrap witnesses but apply a correction on shelley witnesses afterwards

    This is slightly simpler, but it also prevent some nasty things happening with the bootstrap witnesses: the 'Ord' instances used to compare and sort bootstrap witnesses require to serialize them fully, which involve two hashes of bytestrings; when done for 50 inputs, and 100 times in a row in multiple selection this little thing start to matter quite a lot.

  • fc9d4ff
    📍 adjust byron migration test assertion due to recent change
    The fee estimation is now slightly faster, but the approximation is slightly worse, so we end up paying a little more for byron witnesses.

Comments

@KtorZ KtorZ added the IMPROVEMENT Mark a PR as an improvement, for auto-generated CHANGELOG label Sep 9, 2020
@KtorZ KtorZ self-assigned this Sep 9, 2020
@@ -266,7 +267,7 @@ spec = do
Default
payloadMigrate >>= flip verify
[ expectResponseCode @IO HTTP.status202
, expectField id ((`shouldBe` 17). length)
, expectField id ((`shouldBe` 20). length)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fee estimation for Byron witnesses is slightly less accurate than before with this change, so fees are evaluated slightly in excess. We could spend more time tweaking numbers but I think it's good enough already even though it means that transactions costs a little bit more.

@@ -207,7 +208,7 @@ spec = do
testAddressCycling ctx 3
testAddressCycling ctx 10

it "BYRON_MIGRATE_01 - \
Hspec.it "BYRON_MIGRATE_01 - \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we want to revert this to our it, right?

Copy link
Contributor

@piotr-iohk piotr-iohk Sep 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using regular Hspec.it makes sense here I think, because those tests use specific mnemonic wallets, so in case when those tests fail the subsequent run will result in 409 - wallet already exists anyway...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using regular Hspec.it makes sense here I think, because those tests use specific mnemonic wallets

Indeed. We don't want to retry these tests because they use a hard-coded mnemonic. So I changed it back to the standard hspec "it" to make debugging easier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about prefixing the retrying version it with sh to clarify its function? (sorry, couldn't resist 😁)

@@ -167,7 +168,7 @@ spec = do
testAddressCycling 3
testAddressCycling 10

it "SHELLEY_MIGRATE_01_big_wallet - \
Hspec.it "SHELLEY_MIGRATE_01_big_wallet - \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the same here

@@ -273,7 +274,7 @@ spec = do
, expectErrorMessage (errMsg403NothingToMigrate srcId)
]

it "SHELLEY_MIGRATE_02 - \
Hspec.it "SHELLEY_MIGRATE_02 - \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the same here

@@ -338,22 +348,44 @@ data SomeBenchmarkResults where
instance Buildable SomeBenchmarkResults where
build (SomeBenchmarkResults results) = build results

data BenchRndResults s = BenchRndResults
data WalletOverview = WalletOverview
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor

@piotr-iohk piotr-iohk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.

Manually tested on testnet and fee estimation is now instantaneous on random and icarus Byron wallets.
(Would be nice to see full benchmarks after changes 😅)

Copy link
Contributor

@paweljakubas paweljakubas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resigning from ledger bits (using their serialization infrastructure) for performance reason and "hardcoding" input correction numbers basing on what we know in each case is included seems to be very good move. Especially if during fee estimation we invoke this part 100 times

@KtorZ
Copy link
Member Author

KtorZ commented Sep 9, 2020

@piotr-iohk, you're welcome:

All results:                
BenchSeqResults:            
  benchName: 0-percent-seq  
  restoreTime: 138.6 s      
  readWalletTime: 4.515 ms  
  listAddressesTime: 3.228 ms
  listTransactionsTime: 361.9 μs
  estimateFeesTime: 2.271 s 
  walletOverview:           
     number of addresses: 20
     number of transactions: -0
     = Total value of -0 lovelace across 0 UTxOs
      ... 10                0
      ... 100               0
      ... 1000              0
      ... 10000             0
      ... 100000            0
      ... 1000000           0
      ... 10000000          0
      ... 100000000         0
      ... 1000000000        0
      ... 10000000000       0
      ... 100000000000      0
      ... 1000000000000     0
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchRndResults:            
  benchName: 0-percent-rnd  
  restoreTime: 126.7 s      
  readWalletTime: 1.405 ms  
  listAddressesTime: 501.5 μs
  listTransactionsTime: 361.3 μs
  importOneAddressTime: 742.3 μs
  importManyAddressesTime: 77.84 ms
  estimateFeesTime: 1.090 s 
  walletOverview:           
     number of addresses: -0
     number of transactions: -0
     = Total value of -0 lovelace across 0 UTxOs
      ... 10                0
      ... 100               0
      ... 1000              0
      ... 10000             0
      ... 100000            0
      ... 1000000           0
      ... 10000000          0
      ... 100000000         0
      ... 1000000000        0
      ... 10000000000       0
      ... 100000000000      0
      ... 1000000000000     0
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchRndResults:            
  benchName: 0.1-percent-rnd
  restoreTime: 126.8 s      
  readWalletTime: 5.034 ms  
  listAddressesTime: 4.184 ms
  listTransactionsTime: 101.6 ms
  importOneAddressTime: 3.865 ms
  importManyAddressesTime: 84.47 ms
  estimateFeesTime: 8.039 ms
  walletOverview:           
     number of addresses: 83
     number of transactions: 110
     = Total value of 5922204907552 lovelace across 51 UTxOs
      ... 10                0
      ... 100               0
      ... 1000              0
      ... 10000             1
      ... 100000            0
      ... 1000000           2
      ... 10000000          1
      ... 100000000         2
      ... 1000000000        12
      ... 10000000000       11
      ... 100000000000      18
      ... 1000000000000     4
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchRndResults:            
  benchName: 0.2-percent-rnd
  restoreTime: 131.1 s      
  readWalletTime: 10.35 ms  
  listAddressesTime: 9.818 ms
  listTransactionsTime: 153.9 ms
  importOneAddressTime: 8.465 ms
  importManyAddressesTime: 101.3 ms
  estimateFeesTime: 9.720 ms
  walletOverview:           
     number of addresses: 198
     number of transactions: 250
     = Total value of 14480655251559 lovelace across 116 UTxOs
      ... 10                1
      ... 100               1
      ... 1000              1
      ... 10000             1
      ... 100000            2
      ... 1000000           3
      ... 10000000          1
      ... 100000000         6
      ... 1000000000        22
      ... 10000000000       26
      ... 100000000000      42
      ... 1000000000000     10
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchRndResults:            
  benchName: 0.4-percent-rnd
  restoreTime: 139.5 s      
  readWalletTime: 20.22 ms  
  listAddressesTime: 24.88 ms
  listTransactionsTime: 268.2 ms
  importOneAddressTime: 18.06 ms
  importManyAddressesTime: 123.9 ms
  estimateFeesTime: 14.08 ms
  walletOverview:           
     number of addresses: 417
     number of transactions: 479
     = Total value of 32229614849981 lovelace across 270 UTxOs
      ... 10                1
      ... 100               3
      ... 1000              1
      ... 10000             3
      ... 100000            8
      ... 1000000           4
      ... 10000000          6
      ... 100000000         21
      ... 1000000000        45
      ... 10000000000       59
      ... 100000000000      97
      ... 1000000000000     22
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchSeqResults:            
  benchName: 0.1-percent-seq
  restoreTime: 137.7 s      
  readWalletTime: 5.483 ms  
  listAddressesTime: 14.59 ms
  listTransactionsTime: 88.57 ms
  estimateFeesTime: 15.01 ms
  walletOverview:           
     number of addresses: 103
     number of transactions: 110
     = Total value of 5922204907552 lovelace across 51 UTxOs
      ... 10                0
      ... 100               0
      ... 1000              0
      ... 10000             1
      ... 100000            0
      ... 1000000           2
      ... 10000000          1
      ... 100000000         2
      ... 1000000000        12
      ... 10000000000       11
      ... 100000000000      18
      ... 1000000000000     4
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchSeqResults:            
  benchName: 0.2-percent-seq
  restoreTime: 142.5 s      
  readWalletTime: 8.658 ms  
  listAddressesTime: 8.180 ms
  listTransactionsTime: 125.9 ms
  estimateFeesTime: 17.37 ms
  walletOverview:           
     number of addresses: 218
     number of transactions: 250
     = Total value of 14480655251559 lovelace across 116 UTxOs
      ... 10                1
      ... 100               1
      ... 1000              1
      ... 10000             1
      ... 100000            2
      ... 1000000           3
      ... 10000000          1
      ... 100000000         6
      ... 1000000000        22
      ... 10000000000       26
      ... 100000000000      42
      ... 1000000000000     10
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0
                            
BenchSeqResults:            
  benchName: 0.4-percent-seq
  restoreTime: 149.0 s      
  readWalletTime: 35.49 ms  
  listAddressesTime: 24.57 ms
  listTransactionsTime: 268.5 ms
  estimateFeesTime: 27.87 ms
  walletOverview:           
     number of addresses: 437
     number of transactions: 479
     = Total value of 32229614849981 lovelace across 270 UTxOs
      ... 10                1
      ... 100               3
      ... 1000              1
      ... 10000             3
      ... 100000            8
      ... 1000000           4
      ... 10000000          6
      ... 100000000         21
      ... 1000000000        45
      ... 10000000000       59
      ... 100000000000      97
      ... 1000000000000     22
      ... 10000000000000    0
      ... 100000000000000   0
      ... 1000000000000000  0
      ... 10000000000000000 0
      ... 45000000000000000 0

@KtorZ
Copy link
Member Author

KtorZ commented Sep 9, 2020

bors r+

iohk-bors bot added a commit that referenced this pull request Sep 9, 2020
2128: Address slow fee estimation on Byron wallets r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

#2126 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- fc1da51
  📍 **extend post-restoration benchmark wallet overview with number of addresses and transactions**
    We had only the UTxO, which gave little clarity about how many addresses and transactions did that correspond to. In practice, they're of the same order of magnitude, but it's good to have the actual number.

- a234e49
  📍 **do not construct dummy bootstrap witnesses but apply a correction on shelley witnesses afterwards**

  This is slightly simpler, but it also prevent some nasty things happening with the bootstrap witnesses: the 'Ord' instances used to compare and sort bootstrap witnesses require to serialize them fully, which involve two hashes of bytestrings; when done for 50 inputs, and 100 times in a row in multiple selection this little thing start to matter quite a lot.

- fc9d4ff
  📍 **adjust byron migration test assertion due to recent change**
    The fee estimation is now slightly faster, but the approximation is slightly worse, so we end up paying a little more for byron witnesses.

# Comments

<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: KtorZ <matthias.benkort@gmail.com>
…esses and transactions

  We had only the UTxO, which gave little clarity about how many addresses and transactions did that correspond to. In practice, they're of the same order of magnitude, but it's good to have the actual number.
…shelley witnesses afterwards

  This is slightly simpler, but it also prevent some nasty things happening with the bootstrap witnesses: the 'Ord' instances used to compare and sort bootstrap witnesses require to serialize them fully, which involve two hashes of bytestrings; when done for 50 inputs, and 100 times in a row in multiple selection this little thing start to matter quite a lot.
  The fee estimation is now slightly faster, but the approximation is slightly worse, so we end up paying a little more for byron witnesses.
@KtorZ KtorZ force-pushed the KtorZ/2126/fee-estimation-empty-byron branch from fc9d4ff to 3e628f0 Compare September 9, 2020 15:10
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Sep 9, 2020

Canceled.

@KtorZ
Copy link
Member Author

KtorZ commented Sep 9, 2020

bors r+

iohk-bors bot added a commit that referenced this pull request Sep 9, 2020
2121: Fix wallet address pool gap limited to Word8 r=KtorZ a=hasufell

Although with Persistent Word32 will change the
underlying type from SqlInt32 to SqlInt64, it
doesn't matter for sqlite, since they all end
up as INTEGER.

https://www.sqlite.org/datatype3.html

Issue #2120 

2128: Address slow fee estimation on Byron wallets r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

#2126 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- fc1da51
  📍 **extend post-restoration benchmark wallet overview with number of addresses and transactions**
    We had only the UTxO, which gave little clarity about how many addresses and transactions did that correspond to. In practice, they're of the same order of magnitude, but it's good to have the actual number.

- a234e49
  📍 **do not construct dummy bootstrap witnesses but apply a correction on shelley witnesses afterwards**

  This is slightly simpler, but it also prevent some nasty things happening with the bootstrap witnesses: the 'Ord' instances used to compare and sort bootstrap witnesses require to serialize them fully, which involve two hashes of bytestrings; when done for 50 inputs, and 100 times in a row in multiple selection this little thing start to matter quite a lot.

- fc9d4ff
  📍 **adjust byron migration test assertion due to recent change**
    The fee estimation is now slightly faster, but the approximation is slightly worse, so we end up paying a little more for byron witnesses.

# Comments

<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: Julian Ospald <julian.ospald@iohk.io>
Co-authored-by: Julian Ospald <hasufell@posteo.de>
Co-authored-by: KtorZ <matthias.benkort@gmail.com>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Sep 9, 2020

Build failed (retrying...):

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Sep 9, 2020

Build succeeded:

@iohk-bors iohk-bors bot merged commit 0485800 into master Sep 9, 2020
@iohk-bors iohk-bors bot deleted the KtorZ/2126/fee-estimation-empty-byron branch September 9, 2020 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
IMPROVEMENT Mark a PR as an improvement, for auto-generated CHANGELOG
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants