Creation of ContractTx (Java-SDK)


#1

Hey guys,
we’re currently working on the support of contract operations for the Java-SDK and trying to create a contractCreateTx but struggling with the details to get the contract tx successfully deployed.
If we check the resulting signed Tx with goggles against our local node it seems to be valid, but the resulting deployment ends up in a “bad request”
Does anybody have a hint what’s missing up?
Thanks and regards,
Mitch

Here is the input data passed to the RLP encoded array
abiVersion=1,
amount=0,

callData

cb_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnHQYrA==

contractByteCode

cb_+QPvRgGgeN05+tJcdqKtrzpqKaGf7e7wSc3ARZ/hNSgeuHcoXLn5Avv5ASqgaPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8WEbWFpbrjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+QHLoLnJVvKLMUmp9Zh6pQXz2hsiCcxXOSNABiu2wb2fn5nqhGluaXS4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////////////////////7kBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA//////////////////////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uMxiAABkYgAAhJGAgIBRf7nJVvKLMUmp9Zh6pQXz2hsiCcxXOSNABiu2wb2fn5nqFGIAAMBXUIBRf2jyZ2M4/1CIOaukd0nv+ovofvKE8gf7PZmYcBzVOIfFFGIAAK9XUGABGVEAW2AAGVlgIAGQgVJgIJADYAOBUpBZYABRWVJgAFJgAPNbYACAUmAA81tZWWAgAZCBUmAgkANgABlZYCABkIFSYCCQA2ADgVKBUpBWW2AgAVFRWVCAkVBQgJBQkFZbUFCCkVBQYgAAjFaqo6ki

deposit=0,
gas=1000000000,
gasPrice=1000000000,
nonce=1,
ownerId=ak_twR4h7dEcUtc2iSEDv8kB7UFJJDGiEDQCXr85C3fYF8FdVdyo,
ttl=0,
vmVersion=3

The resulting unsgined Tx is

unsginedTx

tx_+QYXKgGhAXXumCWtYwljSCuxk5ohKg5TWIPGtNeATkAofh9VbaJyAbkFS2NiXytRUHZSZ0dnZU4wNSt0SmNkcUt0cnpwcUthR2Y3ZTd3U2MzQVJaL2hOU2dldUhjb1hMbjVBdnY1QVNxZ2FQSm5ZemovVUlnNXE2UjNTZS82aStoKzhvVHlCL3M5bVpod0hOVTRoOFdFYldGcGJyakFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBS0QvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy93QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBdUVBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQStRSExvTG5KVnZLTE1VbXA5Wmg2cFFYejJoc2lDY3hYT1NOQUJpdTJ3YjJmbjVucWhHbHVhWFM0WUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQWdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFQLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vN2tCUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQWdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFZQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBTUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUJRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVBLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vOEFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy91TXhpQUFCa1lnQUFoSkdBZ0lCUmY3bkpWdktMTVVtcDlaaDZwUVh6MmhzaUNjeFhPU05BQml1MndiMmZuNW5xRkdJQUFNQlhVSUJSZjJqeVoyTTQvMUNJT2F1a2QwbnYrb3ZvZnZLRThnZjdQWm1ZY0J6Vk9JZkZGR0lBQUs5WFVHQUJHVkVBVzJBQUdWbGdJQUdRZ1ZKZ0lKQURZQU9CVXBCWllBQlJXVkpnQUZKZ0FQTmJZQUNBVW1BQTgxdFpXV0FnQVpDQlVtQWdrQU5nQUJsWllDQUJrSUZTWUNDUUEyQURnVktCVXBCV1cyQWdBVkZSV1ZDQWtWQlFnSkJRa0ZaYlVGQ0NrVkJRWWdBQWpGYXFvNmtpA4gbwc4ClCY4AICAgIQ7msoAhDuaygC4i2NiX0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQ0M1eVZieWl6RkpxZldZZXFVRjg5b2JJZ25NVnpralFBWXJ0c0c5bjUrWjZnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBbkhRWXJBPT2UFRJa

and the resulting signed Tx is

signedTx

tx_+QZjCwH4QrhAQl7LtSvWmdU/PWBJEznxxTqGZp9avN8E+68pIOS+ImqiEQDXQ6nb9tHVLwXbGNceTRILHLjZhDMiJAP251jAArkGGvkGFyoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgG5BUtjYl8rUVB2UmdHZ2VOMDUrdEpjZHFLdHJ6cHFLYUdmN2U3d1NjM0FSWi9oTlNnZXVIY29YTG41QXZ2NUFTcWdhUEpuWXpqL1VJZzVxNlIzU2UvNmkraCs4b1R5Qi9zOW1aaHdITlU0aDhXRWJXRnBicmpBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQXdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQmdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUtELy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQXVFQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUErUUhMb0xuSlZ2S0xNVW1wOVpoNnBRWHoyaHNpQ2N4WE9TTkFCaXUyd2IyZm41bnFoR2x1YVhTNFlBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzdrQlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBTUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBWUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQ2dBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU1BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzhBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vdU14aUFBQmtZZ0FBaEpHQWdJQlJmN25KVnZLTE1VbXA5Wmg2cFFYejJoc2lDY3hYT1NOQUJpdTJ3YjJmbjVucUZHSUFBTUJYVUlCUmYyanlaMk00LzFDSU9hdWtkMG52K292b2Z2S0U4Z2Y3UFptWWNCelZPSWZGRkdJQUFLOVhVR0FCR1ZFQVcyQUFHVmxnSUFHUWdWSmdJSkFEWUFPQlVwQlpZQUJSV1ZKZ0FGSmdBUE5iWUFDQVVtQUE4MXRaV1dBZ0FaQ0JVbUFna0FOZ0FCbFpZQ0FCa0lGU1lDQ1FBMkFEZ1ZLQlVwQldXMkFnQVZGUldWQ0FrVkJRZ0pCUWtGWmJVRkNDa1ZCUVlnQUFqRmFxbzZraQOIG8HOApQmOACAgICEO5rKAIQ7msoAuItjYl9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNDNXlWYnlpekZKcWZXWWVxVUY4OW9iSWduTVZ6a2pRQVlydHNHOW41K1o2Z0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQW5IUVlyQT09rBWeCw==


#2

Something what we’re wondering - if we analyze the generated tx with goggles, the contractCode and callData seem to have a different encoding type - not sure if this might matter.
f.e. same callData like above then looks like this:
cb_Y2JfQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDQzV5VmJ5aXpGSnFmV1llcVVGODlvYklnbk1WemtqUUFZcnRzRzluNStaNmdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFuSFFZckE9PdO8xgw=


#3

This is the encoding of cb_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnHQYrA== so something is wrong - the calldata should not be encoded twice!

Also the fee is missing in your initial example?


#4

this is the call to our SDK which calculates the fee automatically. that’s why the fee is missing here. thanks for your response! :slight_smile:

@mitch_lbw does that answer help you?


#5

Hi Hans,
the transaction data is what we put in first - and as @marc0olo wrote, the fee is automatically calculated (i also tried with a fixed large one).
My second post shows the transactions callData attribute when we put the signed transaction into the goggles-app - although it says, that the transaction seems to be valid, we get an “bad request” error while deploying the signedTx on the local node.
Actually we’re currently a bit stuck on whats wrong with the tx :frowning:
Thanks and regards,
Mitch


#6

Another idea, too much gas? There is a gas-limit for the microblock, it is 6M, so putting in more than that will make the TX “too large” to fit in a block… (You only pay for the gas used, but you can’t say that there is more available than what can be consumed.)


#7

Hi @hanssv,
we’re now able to generate a valid tx (at least for goggles-aepp) - the problem was the wrong encoding of callData and bytecode.

ValidTx

tx_+QTYCwH4QrhA7fHpT3TKdPDy1UeMJJky4b0VVlffgVZ27ZRqAoheUOCz2gVz8edbZBw6oDTz/IoxH6gkq/SJHTQnDQoFTcI6BbkEj/kEjCoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgq5A/L5A+9GAaB43Tn60lx2oq2vOmopoZ/t7vBJzcBFn+E1KB64dyhcufkC+/kBKqBo8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxYRtYWluuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5AcuguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeqEaW5pdLhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+4zGIAAGRiAACEkYCAgFF/uclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoUYgAAwFdQgFF/aPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8UUYgAAr1dQYAEZUQBbYAAZWWAgAZCBUmAgkANgA4FSkFlgAFFZUmAAUmAA81tgAIBSYADzW1lZYCABkIFSYCCQA2AAGVlgIAGQgVJgIJADYAOBUoFSkFZbYCABUVFZUICRUFCAkFCQVltQUIKRUFBiAACMVoMDAAGGWXV0dvoAgICAAQG4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSA0dw=

Nevertheless the transaction is not deployed on the local node, in the log of the node i can see the following exception
Failed signature check on tx: {error,signature_check_failed}, <<203,117,82,96,10,221,9,92,153,193,25,176,249,93,38,142,201,217,51,51,207,33,69,2,202,18,56,85,53,213,202,61>>
This is a bit strange, because the goggles-aepp is able to validate the signature of the tx…

We also tried different gas and gas price values and fees, all ending up in the same node exception.
Do you have any idea where to point our noses to? :wink:
Thanks,
Mitch


#8

If the node says the signature is wrong it is probably wrong… (at least in the eyes of this particular node!)

Have you used the correct network id when signing?


#9

in our integrationTest we use ae_devnet as network id and our TransactionService is configured to use ae_devnet for signing. so this shouldn’t be the problem as the same Service is being used to sign a spendTx (which is published successfully). but we will doublecheck that!

is it possible that ae_devnet is an invalid network id for certain transaction types?


#10

No, there is no discrimination on network id and transaction type…

If I decode and deserialize the transaction tx_+QTYCwH4... I get a signed contract create, but the signature cannot be verified with ae_devnet as the network id, so I agree with the node :wink: Very hard to tell what has gone wrong, but either you signed the wrong thing or used the wrong key (but I guess that is true for all failed signature checks so it isn’t much of an advice…)


#11

ok now we know at least where we need to look at.

we temporarily assumed the network id is the problem but didn’t check that because as already mentioned other tests are making use of the same TransactionService instance and they should all use the same sign config which is configured to ae_devnet. probably there is somewhere a new instance of the configuration created which points to ae_uat by default

thanks! :slight_smile: