Open ashisherc opened 1 year ago
cc @dnadales
cc @amesgen
Generally, there are no guarantees that the tx binary format evolves in a backwards-compatible manner from era to era, as was the case from e.g. Byron to Shelley. So there is no general guarantee that submitting the same bytes will work with era index i+1
when it worked with i
.
On the other hand, Ledger does not randomly change the format, so a serialized Alonzo tx might well be also a valid Babbage tx. Can you maybe post the CBOR of the tx you are trying to submit as a Babbage tx?
@amesgen I find your comment contradicting your own comment. Though I explain the issue in the description and is what you describe in your first paragraph, but it should work as per your second paragraph. Below the tx cbor I am submitting with era 5
84a400828258203a79a6a834e7779c67b0b3cbd3b7271883bbbeac15b1a89d78f057edc25e000b008258203a79a6a834e7779c67b0b3cbd3b7271883bbbeac15b1a89d78f057edc25e000b010182825839007d5a2560d23c3443b98d84c57b0c491311da4b3098de1945c7bcfc4c63ea8c5404f9ed9ae80d95b5544857b2011e3f26b63ddc3be1abd42d1a001e84808258390009ecea977429fa7a4993bc045ea618f3697e6b8eac9d5ea68bba7e4b63ea8c5404f9ed9ae80d95b5544857b2011e3f26b63ddc3be1abd42d821a560ea01ca4581c47be64fcc8a7fe5321b976282ce4e43e4d29015f6613cfabcea28eaba244546573741a3b97c0aa51576f52456d706972654c696368303037391a3443f4a0581c4cd2ea369880853541c5f446725f3e4ecaf141635f0c56c43104923ba14574464c41431b0de0b6b346d4b018581c85ef026c7da6a91f7acc1e662c50301bcce79eb401a3217690aa7044a14574464c41431b000000022eaca140581c92bd3be92d6a6eadd7c01ce9ff485809f3f2eb36845cd7a25c9177bfa14b546f20746865206d6f6f6e01021a0002b9b5031a05a18ef7a100818258202726733baa5c15d8d856c8d94e7d83bcfc7f5661ec7f952f052f311a2443feb258405f9d3d8a703baf700a3015994a3e8702fd7fe2e25d640487944b32ea999f36b314be9674be09b8b8f2c678976ecf994c83086180e854120d81243476c2b89e05f5f6
It should generally work as all previous era tx is a valid Babbage era tx as per the spec. Note that, it does not just return an error, but disconnects the connection, which generally happens when you are communicating with a bad format. But it works well if I use era as 4
cc @JaredCorduan
I don't think there is a contradiction, backwards-compatibility is not guaranteed in general (Byron-to-Shelley is the counterexample), but at the same time, it can be satisfied for e.g. Alonzo-to-Babbage.
I just tested that deserializing your transaction (after wrapping it appropriately) can be deserialized using the code in this repo both with era index 4
and 5
, i.e. for 5
, prepending 8205d818590210
in hex, corresponding to the CBOR
82 # array(2)
05 # unsigned(5)
d8 18 # tag(24)
59 0210 # bytes(528)
works fine; so the error must be somewhere else.
I can understand that the deserializing works, as it should. Does this mean the problem lies with Ouroboros Network? Because submitting this tx works only with era 4, and not 5 via the mini protocol.
c @coot
There were no protocol level changes since a very long time, so I'd be quite surprised if the problem lives in ouroboros-network
. What error do you get when you submit the tx? Does the local-tx-submission
mini-protocol returns without an error? Are you using cardano-cli
or some 3rd party tool for submitting the tx?
if we use cardano-cli, it does not require to define the era hence it calculates the correct era and submits the tx thus works fine.
I am using the local tx submit mini protocol directly as detailed in the description, hence I now have to define the tx era myself and that is how this issue is found. If the code is not changed for a long time, possible the issue is present from a long time because so far only IOG tools submit the tx, and some other community tools which submit the tx figures out the era manually and define it before submitting (as described if the correct era is defined it works)
If we submit an alonzo era tx in babbage era, with era number as babbage (5), the node just disconnects the connection without an error msg ofc. Note as described in the previous messages, if we submit the same tx with era as 4 while in Babbage era it works fine.
~What protocol error is returned by the responder side of the local-tx-submission
mini-protocol?~
Oh, I see there's no message back. Is there anything in the cardano-node
logs? It should log the exception thrown by the mini-protocol.
For my own tools, this is the work-around I have to do to ensure I'm submitting the right era for a given transaction. It feels fragile and prone to bugs even though it currently works. If I submit a wrong era, like @ashisherc said, you just get dropped by the node and disconnected with no error message.
internal val era: Int by lazy {
try {
val txArray = CborObject.createFromCborByteArray(signedTxCborByteArray) as CborArray
if (txArray.elementAt(txArray.size() - 2) is CborSimple) {
// alonzo or babbage
val txBody = txArray.elementAt(0) as CborMap
val txDestsArray = txBody[TX_DESTS_INDEX] as CborArray
if ((!txDestsArray.isEmpty && (txDestsArray.elementAt(0) is CborMap)) ||
(txBody[TX_COLLAT_RETURN_INDEX] != null) ||
(txBody[TX_COLLAT_TOTAL_INDEX] != null) ||
(txBody[TX_REFERENCE_INPUTS_INDEX] != null)
) {
// in Babbage, the out UTXOs are a CborMap or it's using one of the new features
log.debug("Submitting BABBAGE tx")
CardanoEra.BABBAGE.eraNumber
} else {
log.debug("Submitting ALONZO tx")
CardanoEra.ALONZO.eraNumber
}
} else {
log.debug("Submitting MARY tx")
CardanoEra.MARY.eraNumber
}
} catch (e: Throwable) {
log.error("Error decoding MsgSubmitTx!", e)
CardanoEra.MARY.eraNumber
}
}
We could not reproduce this in a local (Consensus) test. In future releases, we will enable certain tracers by default, which include the tracers that log exceptions that cause local client disconnection. In the meantime could you set the severity of the local tx submission protocol to Debug
?
"mapSeverity": {
"cardano.node.LocalTxSubmissionProtocol": "Debug"
}
update: investigating - please keep this open
@dnadales no logs even after the suggested config change. the connection is just dropped.
External
Summary I am using the local transaction submission mini protocol, while submitting a transaction that is built using Alonzo spec, and being submitted with era number 5 (Babbage), the node disconnects the connection and does not return an error message as well.
Steps to reproduce Build an Alonzo era tx, Prepare payload with era as
5
Submit using the local transaction submission mini protocolExpected behaviour Since Babbage era tx spec is Alonzo compatible, a tx built using Alonzo only spec is a valid Babbage era tx. The protocol and node should accept the tx.