You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every transaction has to be converted to bytes at one point before being sent to the node and that is when we know, for certain, what the contents of the transaction will be. Based on that, instead of setting some dynamic parts of the transaction that depend on other dynamic parts like policies prematurely (e.g. predicateData that depends on the policies count), we should postpone the resolution of the actual dynamic data until the very end when the transaction is being serialized.
By doing this we'd ensure that no conflicts are possible (e.g. predicateData gets set based on one policy count, after which another policy gets added), as well as simplify the transaction encoding logic because there'd be only one place where all the resolution happens.
Caution
This is a major refactoring issue and one should tread carefully in implementing it.
This discussion was converted from issue #2156 on November 06, 2024 08:08.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Every transaction has to be converted to bytes at one point before being sent to the node and that is when we know, for certain, what the contents of the transaction will be. Based on that, instead of setting some dynamic parts of the transaction that depend on other dynamic parts like policies prematurely (e.g.
predicateData
that depends on the policies count), we should postpone the resolution of the actual dynamic data until the very end when the transaction is being serialized.By doing this we'd ensure that no conflicts are possible (e.g.
predicateData
gets set based on one policy count, after which another policy gets added), as well as simplify the transaction encoding logic because there'd be only one place where all the resolution happens.Caution
This is a major refactoring issue and one should tread carefully in implementing it.
Beta Was this translation helpful? Give feedback.
All reactions