-
Notifications
You must be signed in to change notification settings - Fork 7
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
Stacks Transactions being rejected - Contract deployments #166
Comments
I did some testing and have some findings to add. The contract deployment seems to fail when raw transaction is >= 16390 bytes. This is pretty limiting for a contract deployment. That leaves about 8k bytes for a contract, which is 100-200 lines of code (obviously depending on the number of characters per line, so this is an estimate). I tested this on xverse where these large payloads actually caused my Ledger Nano S Plus to crash. On the Leather wallet, even small contract deployment transactions are rejected with the error Here are some raw tx bytes that can be used to reproduce: Working Payload (16388 bytes)
Broken Payload (16390 bytes)
|
what device were you running on? nanosplus? i am afraid that such large transactions is not possible to handle, unless we change to another parsing strategy, a streaming base parser or split the processing of large contract deployment transactions in more than one APDU instruction |
nanosplus, yes |
Thanks for reporting this, we would look at this soon |
Isn't the rust canonical decoder from the stacks-blockchain streaming based? 🤔 |
Actually, we do not check the semantically/syntax of all the contract code due to limited resources on our side, it is likely as reported by @lgalabru the size of the contract that the transaction carries in, which is larger than the available memory resources in the ledger device |
cc @pete-watters, it looks like Leather have their own bugs that we're not experiencing with Xverse |
Thanks @lgalabru . If there are some contracts that are being accepted by Xverse but not but Leather it could indeed be an issue in Leather. That message If you can please open an issue with steps to reproduce in https://github.com/leather-io/extension/issues we can take a look and help pinpoint the issue |
Can I please confirm that we are saying fundamentally this is the memory size issue with the particular ledger device? I tried with Nano S Plus and Nano X, both failed to deploy. |
This would be great to have resolved - I have a ledger x and an old nano to test on as well. |
hi @neithanmo! any update on this issue? |
I'm working on a Stacks application (https://hermetica.fi) and we're looking to deploy Stacks contracts with Ledger through @lgalabru tool. It'd be great to get this issue solved asap. |
@lgalabru and @pete-watters I have added your comment about contract deployments failing with Leather/Ledger regardless of size here: leather-io/extension#4683 (comment) |
Hi @lgalabru @pete-watters , to get a better understanding of the potential size of this transaction, could someone share the serialized transaction that triggers this issue? I'd like to use it to test the various solutions I'm considering to fix this problem. but can you elaborate on or share the transaction that was rejected regardless of the size? it is strange that it gets rejected and the only way to tell is with the specific transaction being processed with Leather |
thanks @neithanmo ! Leather had their own bug that they'll be fixing with leather-io/extension#4683 (comment). Post-patch, Xverse and Leather are aligned in their behavior:
Like we shared earlier the contract size limit is way too low for developers - to the point where it's unusable. |
so the faulty payload is just 2 bytes longer? |
Yes. |
Any clue on what's going on @neithanmo? |
this payload which is supposed to break the app is at least being parsed correctly in our rust unit testing, so it is ok so far, it points then to a possible issue with the input memory on the device.
I am checking if increasing flash memory would suffice, but this solution will work on nanosplus, stax and flex devices only |
indeed:
you can see that our limit is 16384 bytes of flash, we can increase this more, but this could cause the app size to grow more, limiting the amount of ledger applications you can install on your device along with stacks. increasing the size initially is the fastest solution and probably a temporal solution while we come up with something else, this something else would require changes on the app itself and JS package(keeping in mind to maintain the public API the same) to handle this smart contract deployment transaction differently while maintaining consistency and generality with the other stacks transaction types |
I'm 200% biased, but helping developers operating safely seems more important than helping users owning a legacy model Nano S (no longer sold), maxing out the number of apps they can get on their device :) I agree, nanos is in fact discontinued |
I'm looking at some contracts that I wrote in the past:
Seems like 50KB to 75KB would give us some good margin. @neithanmo would it be reasonable? |
Yep, I would support increasing the flash size. Anecdotally, most people who are using Stacks on Nano S type devices like have only 1-2 applications on their device (Bitcoin being the other one). |
You went ahead and answered what was about to be my next question, which was a reasonable buffer size. |
yes, There was a request(years ago) to reduce the app size for nanos users to be able to install it along with bitcoin app, we did that. |
fixed via #172 |
Fantastic, thank you so much for your help with this issue! |
Hi everyone, The fix has been merged on Ledger's side. We're good with this and @lgalabru we can close this issue. Thanks @neithanmo |
@lgalabru @sourajyoti-gupta we just managed to deploy a contract with Txtx + ledger s nano, so we are good! |
hello @neithanmo,
we're working on https://www.txtx.sh and experiencing an issue similar to the one opened here #159.
the difference here is that our issue is not related to signed messages, but transactions deploying certain contracts.
it's hard to tell at this point if the trigger is contract size, or presence of a unsupported data type in the contract.
do you have some test vectors deploying contracts? how can we help?
🔗 zboto Link
The text was updated successfully, but these errors were encountered: