Hello guys,
I just wanted to know which SDK(s) already support generalized accounts? I discovered a WIP-branch in the aepp-sdk-js but it isn’t merged yet.
I want to implement support for generalized accounts in the Java SDK and wanted to see how this is done in other SDKs.
Is there any working implementation where I can have a look at?
Hey @marco.chain,
During last week’s dev update call, Andrea said that they were currently preparing a new Python SDK release that was going to have GA support. @noandrea please clarify 
Best,
Albena
The Elixir SDK supports GA attach and meta transactions, although at this point meta transactions can’t be nested.
There is aslo a wip branch for the python SDK, we have a working version but there is some polish to be made still.
I believe that we will release a version for the python SDK by the end of the week.
It is not merged yet, and there will be refactoring involved but you can check out the branch feature/ga for they Py SDK.
There is also some documentation to walk you to the process here. The documentation is executable but you will have to install the branch version using something like the command:
poetry build && pip install build/aepp_sdk-4.1.0-py3-none-any.whl
then save the script from the docs and execute it.
EDIT:
it has been merged: links updated
@noandrea is there any reason why the tx-types required for generalized accounts are not inluded in the swagger.yaml?
I mean it isn’t a problem to define them on our own but in my opinion it would be good to have it included in the swagger.yaml
there isn’t a specific reason afaik, probably it was just an oversight.
I’ll see if I can make a pr for that.
the pr for GA txs in the swagger file has been merged PT-167970620 - Add GA Attach/Meta Tx definition in swagger yaml/json by noandrea · Pull Request #2669 · aeternity/aeternity · GitHub
so it will be in the next release.
and with the last release also the is sdk supports ga
picking this up again since I want to add support for generalized accounts in the Java SDK.
@hanssv.chain can you point me to a document that describes how the auth_fun hash needs to be generated? need that for the GAAttachTx and this is what I am currently struggling with.
I don’t remember, and the documentation has been changed and things have moved around a bit since I last looked at it…
But if my memory serves me right it should be a 32-byte binary for an AEVM function, and a 4-byte binary (padded on the right side with 28-bytes of zeros) with the “symbol identifier” for a FATE function. The best way to get a grip on this is probably to have a look a the aega_SUITE test suite. A quick look suggests that aega_test_utils:auth_fun_hash/2 is doing this for the test suite.
ok, I will try to figure this out. thanks! I guess I can ignore AEVM as it’s being deprecated, right? (assuming I don’t want to be backwards compatible)
AEVM is being deprecated in the sense that you can’t add new Generalized accounts with AEVM authorization functions. It does not mean that existing GAs stop working… But I think the number of GAs on chain can be counted using the fingers from no more than one hand, so perhaps that is overkill
what is that “symbol identifier” about? I am wondering about the implementation of several SDKs compared to the testsuite. unfortunately I cannot understand what the Erlang code does
Testsuite:
auth_fun_hash(Name, AEVMTypeInfo) ->
case ?IS_AEVM_SOPHIA(aega_SUITE:vm_version()) of
true -> aeb_aevm_abi:type_hash_from_function_name(Name, AEVMTypeInfo);
false -> {ok, <<(aeb_fate_code:symbol_identifier(Name)):4/binary, 0:(28*8)>>}
end.
Elixir SDK:
defp hash_from_function_name(auth_fun, type_info, vm) do
case vm do
:aevm ->
:aeb_aevm_abi.type_hash_from_function_name(auth_fun, type_info)
:fate ->
Hash.hash(auth_fun)
end
end
I used the Elixir SDK in this example for the comparison. So does this mean the implementations of the SDKs are outdated?
When trying to hash the function name like the other SDKs I always get Internal error: bad_function_hash when performing a dry-run for the GAAttachTx.
edit
authorize I get following byte-array as result but the dry-run still fails 
That looks correct. The “symbol identifier” is nothing else than the first four bytes of the Blake2b hash of the name of the function. bad_function_hash is only returned if there is no function in the contract matching the function hash.
Can you post the full transaction perhaps?
is the tx hash enough for you to analyize? this is an example:
tx_+QE8UAGhARn+qjn2Ub/T/1Aw0uzzMLj2QE3LMFOdYyW0KA+RcS4JAbiy+LBGA6Cqm4ajQrzYRtSDA00sY+G3SGO3mpK2lf4dlJHTM0JGF8C4g7hV/kTWRB8ANwFHADcAGgaCAAEDP/5GZxOgADcCl0AHl0AMAQAMAQInDAQdAAD+bPJXCwA3AQcXdwAIPAIE+wNNTm90IGluIEF1dGggY29udGV4dAED/6gvAxFE1kQfEWluaXQRRmcToB10b19zaWduEWzyVwslYXV0aG9yaXplgi8AhTQuMy4wAKJs77+9VwsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgwUAA4ZKCGoVsAAAg0k+AIQ7msoAqisRRNZEHxufAKAZ/qo59lG/0/9QMNLs8zC49kBNyzBTnWMltCgPkXEuCafPdjs=
No, the TX hash is not enough, but that would be th_... you provided a (serialized and encoded) transaction which is exactly what I asked for (with a couple of extra serializations).
The Tx deserialized is:
{aetx,ga_attach_tx,aega_attach_tx,319,
#ga_attach_tx{owner_id = {id,account,
<<25,254,170,57,246,81,191,211,255,80,48,210,236,243,48,
184,246,64,77,203,48,83,157,99,37,180,40,15,145,113,46,
9>>},
nonce = 1,
code = <<248,176,70,3,160,170,155,134,163,66,188,216,70,
212,131,3,77,44,99,225,183,72,99,183,154,146,182,
149,254,29,148,145,211,51,66,70,23,192,184,131,
184,85,254,68,214,68,31,0,55,1,71,0,55,0,26,6,
130,0,1,3,63,254,70,103,19,160,0,55,2,151,64,7,
151,64,12,1,0,12,1,2,39,12,4,29,0,0,254,108,242,
87,11,0,55,1,7,23,119,0,8,60,2,4,251,3,77,78,111,
116,32,105,110,32,65,117,116,104,32,99,111,110,
116,101,120,116,1,3,255,168,47,3,17,68,214,68,31,
17,105,110,105,116,17,70,103,19,160,29,116,111,
95,115,105,103,110,17,108,242,87,11,37,97,117,
116,104,111,114,105,122,101,130,47,0,133,52,46,
51,46,48,0>>,
auth_fun = <<108,239,191,189,87,11,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>,
call_data = <<43,17,68,214,68,31,27,159,0,160,25,254,170,
57,246,81,191,211,255,80,48,210,236,243,48,
184,246,64,77,203,48,83,157,99,37,180,40,15,
145,113,46,9>>,
ct_version = #{abi => 3,vm => 5},
fee = 81400000000000,gas = 4800000,gas_price = 1000000000,
ttl = 0}}
So the auth_fun field doesn’t look right, and doesn’t match what you wrote… It should be <<108, 242, 87, 11, 0, 0, ...>> my guess is you are using a stupid language that mixes up bytes and signed bytes? The contract looks good, and with the right auth_fun I think it will work.
thanks! at least I solved that problem now 
unfortunately I am doing sth. wrong with the GAMetaTx and I am not sure what it is. maybe you can have a look at these transactions and observe my mistake
GAAttachTx
tx_+QGECwH4QrhAxJjUcM9DoSASEUUO+f2HCpd4qIWYGzK2PPAcS84izM4ZpOs1kOoHPFqueGXiUi8ODYi6teUHJuz3mAH9ziYOD7kBO/kBOFABoQGz/swxQd0T+aLjS1XdU/S3xQezd3psx0Idb88BaTnxUAG4sviwRgOgqpuGo0K82EbUgwNNLGPht0hjt5qStpX+HZSR0zNCRhfAuIO4Vf5E1kQfADcBRwA3ABoGggABAz/+RmcToAA3ApdAB5dADAEADAECJwwEHQAA/mzyVwsANwEHF3cACDwCBPsDTU5vdCBpbiBBdXRoIGNvbnRleHQBA/+oLwMRRNZEHxFpbml0EUZnE6AddG9fc2lnbhFs8lcLJWF1dGhvcml6ZYIvAIU0LjMuMACgbPJXCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDBQADhkn1ybaQAACB4oQ7msoAqisRRNZEHxufAKCz/swxQd0T+aLjS1XdU/S3xQezd3psx0Idb88BaTnxUCtBOVk=
Corresponding GAMetaTx (has a SpendTx included)
tx_+NULAcGAuM/4zVEBoQGz/swxQd0T+aLjS1XdU/S3xQezd3psx0Idb88BaTnxUI0rEWzyVwsb74Qd3VxiA4cBnQm1YNgAgsNQhDuaygAAuIf4hQsBwYC4f/h9DAGhAbP+zDFB3RP5ouNLVd1T9LfFB7N3emzHQh1vzwFpOfFQoQExD3OUfAFcRuY+wfPPwaTtX1xIlmDa5OL3AdkDjJNu7ogN4Lazp2QAAIYP+IGP8AAAAKRzcGVudCB1c2luZyBhIGdlbmVyYWxpemVkIGFjY291bnQgPSlGrDl4
the GAMetaTx seems to be invalid and I am not able to execute a dry-run for it (getting internal server error)
Note
BlindAuth contract with authorize as auth-functionThe signature is wrong… It should be an empty list of signatures, not a list with one 0-byte signature.