fix(sequencing): fix transactions serializtion

[Yael-Starkware]

No description provided.

[reviewable-StarkWare]

This change is 

[Yael-Starkware]

• fix(sequencing): fix transactions serializtion #3149 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[DvirYo-starkware]

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @dafnamatsry and @Yael-Starkware)

---

crates/sequencing/papyrus_consensus_orchestrator/resources/central_invoke_tx.json line 18 at r1 (raw file):

                "max_amount": "0x0",
                "max_price_per_unit": "0x0"
            },

Is no change needed in L1Handler tx?

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 117 at r1 (raw file):

    }
}

Why not use a new type we defined instead of a map? As far as I know, it has the same serialization as a map.

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 145 at r1 (raw file):

    pub fee_data_availability_mode: u32,
    pub hash_value: TransactionHash,
}

Is there a reason for the order of the fields in a struct? If doesn't I think it will be better to save the order in all the transactions.

[Yael-Starkware]

Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @dafnamatsry and @DvirYo-starkware)

---

crates/sequencing/papyrus_consensus_orchestrator/resources/central_invoke_tx.json line 18 at r1 (raw file):

Previously, DvirYo-starkware wrote…

Is no change needed in L1Handler tx?

no, the L1handler collects fees on L1 with a different mechanism.

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 117 at r1 (raw file):

Previously, DvirYo-starkware wrote…

Why not use a new type we defined instead of a map? As far as I know, it has the same serialization as a map.

I was being consistent with the pythonic type definition - which is a mapping.

I can change it to be a struct if you think it's better.

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 145 at r1 (raw file):

Previously, DvirYo-starkware wrote…

Is there a reason for the order of the fields in a struct? If doesn't I think it will be better to save the order in all the transactions.

sure, will do in a separate PR. added a todo.

[DvirYo-starkware]

Reviewed all commit messages.
Reviewable status: 3 of 4 files reviewed, 1 unresolved discussion (waiting on @dafnamatsry and @Yael-Starkware)

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 117 at r1 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

I was being consistent with the pythonic type definition - which is a mapping.

I can change it to be a struct if you think it's better.

I think it will be better. We also do the same for transactions, as far as I remember.

[Yael-Starkware]

Reviewable status: 3 of 4 files reviewed, 1 unresolved discussion (waiting on @dafnamatsry and @DvirYo-starkware)

---

crates/sequencing/papyrus_consensus_orchestrator/src/cende/central_objects.rs line 117 at r1 (raw file):

Previously, DvirYo-starkware wrote…

I think it will be better. We also do the same for transactions, as far as I remember.

done.

[DvirYo-starkware]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @dafnamatsry)