Add type information for hz_sophia

This one was much simpler to do than hz_aaci, since it doesn't introduce any new types.

I could have made note of some of the conventions, where a type can be represented in multiple
ways in Sophia syntax, or where these functions are actually more lenient than the compiler, but
it isn't as easy to break those notes up from the basic function usage, like it was in hz_aaci,
where those aforementioned new types are used.

doc/overview.edoc

@@ -1,6 +1,5 @@
-@author Craig Everett <craigeverett@qpq.swiss> [https://zxq9.com]
+@author Craig Everett <craigeverett@qpq.swiss> [https://git.qpq.swiss/QPQ-AG/hakuzaru]
-@author Jarvis Carrol <jarviscarrol@qpq.swiss> [https://jarviscarroll.net/]
+@version 0.9.1
-@version 0.9.2
 @title Hakuzaru: Gajumaru blockchain bindings for Erlang
 
 @doc
@@ -22,7 +21,7 @@ After startup `hz_man' must be given the address and port of a list of Gajumaru
 Note that the service nodes will need to have the dry-run endpoint enabled and the internal service query port made available in order to provide dry-runs and transaction submission.
 
 When configuring chain nodes a list of nodes should be provided.
-To avoid sync issues in the case of fast transaction formation/submission to the chain, only one node from the list of chain nodes is used for submitting transactions and querying `next_nonce/1'.
+To avoid sync issues in the case of fast transaction formation/submission to the chain, only one node from the list of chain nodes is used for submitting transactions and querying `next_nonce/1`.
 This node is called "the sticky node".
 
 The first node in the list of chain nodes provided during configuration is designated as the sticky node.

ebin/hakuzaru.app

@@ -3,7 +3,7 @@
               {included_applications,[]},
               {applications,[stdlib,kernel]},
               {description,"Gajumaru interoperation library"},
-              {vsn,"0.9.2"},
+              {vsn,"0.9.1"},
               {modules,[hakuzaru,hz,hz_aaci,hz_fetcher,hz_format,hz_grids,
                         hz_key_master,hz_man,hz_sophia,hz_sup]},
               {mod,{hakuzaru,[]}}]}.

src/hakuzaru.erl

@@ -6,7 +6,7 @@
 %%% @end
 
 -module(hakuzaru).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Craig Everett <ceverett@tsuriai.jp>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
 -license("GPL-3.0-or-later").

src/hz.erl

@@ -23,7 +23,7 @@
 %%% @end
 
 -module(hz).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Craig Everett <ceverett@tsuriai.jp>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
 -license("GPL-3.0-or-later").
@@ -45,7 +45,7 @@
          acc/1, acc_at_height/2, acc_at_block_id/2,
          acc_pending_txs/1,
          next_nonce/1,
-         dry_run/1, dry_run/2, dry_run/3, % dry_run_map/1,
+         dry_run/1, dry_run/2, dry_run/3, dry_run_map/1,
          tx/1, tx_info/1,
          post_tx/1,
          contract/1, contract_code/1, contract_source/1,
@@ -125,14 +125,13 @@
 %   "info"          => contract_byte_array(),
 %   "miner"         => account_id(),
 %   "nonce"         => non_neg_integer(),
+%   "pow"           => [non_neg_integer()],
 %   "prev_hash"     => microblock_hash(),
 %   "prev_key_hash" => keyblock_hash(),
-%   "seal"          => #{"data" => [int()],
-%                        "signature" => signature()}
 %   "state_hash"    => block_state_hash(),
 %   "target"        => non_neg_integer(),
 %   "time"          => non_neg_integer(),
-%   "version"       => 1}.
+%   "version"       => 5}.
 % </pre>
 -type microblock_header()   :: #{string() => term()}.
 % <pre>
@@ -354,7 +353,7 @@ top_height() ->
 
 
 -spec top_block() -> {ok, TopBlock} | {error, Reason}
-    when TopBlock :: microblock_header() | keyblock(),
+    when TopBlock :: microblock_header(),
          Reason   :: chain_error().
 %% @doc
 %% Returns the header of the current top block.
@@ -662,10 +661,9 @@ dry_run(TX, Accounts, KBHash) ->
     request("/v3/dry_run", JSON).
 
 
-% TODO
+dry_run_map(Map) ->
-%dry_run_map(Map) ->
+    JSON = zj:binary_encode(Map),
-%    JSON = zj:binary_encode(Map),
+    request("/v3/dry_run", JSON).
-%    request("/v3/dry_run", JSON).
 
 
 -spec decode_bytearray_fate(EncodedStr) -> {ok, Result} | {error, Reason}
@@ -790,9 +788,9 @@ contract_code(ID) ->
          Result :: {ok,      Source}
                  | {project, Bundle}
                  | {error,   Reason},
-         Source :: binary(),
+         Source :: string(),
          Bundle :: [{FilePath :: string(), Contents :: binary()}],
-         Reason :: chain_error() | string().
+         Reason   :: chain_error() | string().
 %% @doc
 %% Retrieve the code of a contract as represented on chain.
 
@@ -811,14 +809,10 @@ extract(Blobby) ->
 
 extract2(TarBaby) ->
     case erl_tar:extract({binary, TarBaby}, [memory, compressed]) of
-        {ok, [{_, Source}]} ->
-            {ok, Source};
         {ok, Bundle} ->
             {project, Bundle};
-        {error,invalid_tar_checksum} ->
-            {ok, TarBaby};
         Error ->
-            ok = io:format("erl_tar:extract/2 error: ~tp~n", [Error]),
+            io:format("Dis chit happen: ~tp~n", [Error]),
             {ok, TarBaby}
     end.
 
@@ -901,12 +895,6 @@ request(Path) ->
     hz_man:request(unicode:characters_to_list(Path)).
 
 
--spec request(Path, Payload) -> {ok, Value} | {error, Reason}
-    when Path    :: unicode:charlist(),
-         Payload :: unicode:charlist(),
-         Value   :: map(),
-         Reason  :: hz:chain_error().
-
 request(Path, Payload) ->
     hz_man:request(unicode:characters_to_list(Path), Payload).
 
@@ -942,7 +930,7 @@ contract_create(CreatorID, Path, InitArgs) ->
             Gas = 500000,
             GasPrice = min_gas_price(),
             contract_create(CreatorID, Nonce,
-                            Gas, GasPrice, Amount, TTL,
+                            Amount, TTL, Gas, GasPrice,
                             Path, InitArgs);
         Error ->
             Error
@@ -1654,14 +1642,6 @@ convert([], [], _, Terms, []) ->
 convert([], [], _, _, Errors) ->
     {error, Errors}.
 
--spec sign_tx(Unsigned, SecKey) -> Result
-    when Unsigned :: string(),
-         SecKey   :: binary(),
-         Result   :: {ok, SignedTX} | {error, Reason},
-         SignedTX :: binary(),
-         Reason   :: chain_error().
-%% @doc
-%% Signs transaction data with the provided secret key for the currently selected network.
 
 sign_tx(Unsigned, SecKey) ->
     case network_id() of
@@ -1669,15 +1649,6 @@ sign_tx(Unsigned, SecKey) ->
         Error           -> Error
     end.
 
-
--spec sign_tx(Unsigned, SecKey, NetworkID) -> SignedTX
-    when Unsigned  :: string(),
-         SecKey    :: binary(),
-         NetworkID :: string(),
-         SignedTX  :: binary().
-%% @doc
-%% Signs transaction data with the provided secret key using the provided network ID.
-
 sign_tx(Unsigned, SecKey, MNetworkID) ->
     UnsignedBin = unicode:characters_to_binary(Unsigned),
     NetworkID   = unicode:characters_to_binary(MNetworkID),
@@ -1697,21 +1668,10 @@ sign_tx(Unsigned, SecKey, MNetworkID) ->
     gmser_api_encoder:encode(transaction, SignedTX).
 
 
--spec spend(SenderID, SecKey, RecipientID, Amount, Payload) -> {ok, Result} | {error, Reason}
+spend(SenderID, SecKey, ReceipientID, Amount, Payload) ->
-    when SenderID    :: string(),
-         SecKey      :: binary(),
-         RecipientID :: string(),
-         Amount      :: non_neg_integer(),
-         Payload     :: binary(),
-         Result      :: term(), % FIXME
-         Reason      :: chain_error() | string().
-%% @doc
-%% Forms a spend transaction and submits it to the chain.
-
-spend(SenderID, SecKey, RecipientID, Amount, Payload) ->
     case status() of
         {ok, #{"top_block_height" := Height, "network_id" := NetworkID}} ->
-            spend(SenderID, SecKey, RecipientID, Amount, Payload, Height, NetworkID);
+            spend(SenderID, SecKey, ReceipientID, Amount, Payload, Height, NetworkID);
         Error  ->
             Error
     end.
@@ -1738,23 +1698,6 @@ spend(SenderID, SecKey, RecipientID, Amount, Payload, Height, NetworkID) ->
     end.
 
 
--spec spend(SenderID, SecKey, RecipientID, Amount,
-            GasPrice, Gas, TTL, Nonce, Payload, NetworkID) -> {ok, Result} | {error, Reason}
-    when SenderID    :: string(),
-         SecKey      :: binary(),
-         RecipientID :: string(),
-         Amount      :: non_neg_integer(),
-         GasPrice    :: pos_integer(),
-         Gas         :: pos_integer(),
-         TTL         :: non_neg_integer(),
-         Nonce       :: non_neg_integer(),
-         Payload     :: binary(),
-         NetworkID   :: unicode:chardata(),
-         Result      :: term(), % FIXME
-         Reason      :: chain_error() | string().
-%% @doc
-%% Forms a spend transaction and submits it to the chain.
-
 spend(SenderID,
       SecKey,
       RecipientID,
@@ -1867,10 +1810,6 @@ spend3(DSenderID,
     when Message :: binary(),
          SecKey  :: binary(),
          Sig     :: binary().
-%% @doc
-%% Accepts a string to be signed, prepends the prefix `"Gajumaru Signed Message:\n"',
-%% encodes the string with `vencode/1', then hashes the encoded message and signs the
-%% hash.
 
 sign_message(Message, SecKey) ->
     Prefix = message_sig_prefix(),
@@ -1949,12 +1888,6 @@ eu(N, Size) ->
     when Binary :: binary(),
          SecKey :: binary(),
          Sig    :: binary().
-%% @doc
-%% This procedure signs an arbitrary binary blob with a special binary prefix
-%% attached. The reason for the binary prefix is to prevent signing of dangerous
-%% binaries which could be used to authorized dangerous actions on chain.
-%% The signature target becomes: `<<"Gajumaru Signed Binary:", Binary/binary>>'
-%% before being hashed, and then the resulting hash is signed.
 
 sign_binary(Binary, SecKey) ->
     Prefix = binary_sig_prefix(),
@@ -1969,8 +1902,6 @@ sign_binary(Binary, SecKey) ->
          PubKey  :: pubkey(),
          Result  :: {ok, Outcome :: boolean()}
                   | {error, Reason :: term()}.
-%% @doc
-%% Verifies a signature created with the `sign_binary/2' function.
 
 verify_bin_signature(Sig, Binary, PubKey) ->
     case gmser_api_encoder:decode(PubKey) of

src/hz_aaci.erl

@@ -10,7 +10,7 @@
 %%% @end
 
 -module(hz_aaci).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Jarvis Carroll <spiveehere@gmail.com>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
 -license("GPL-3.0-or-later").
@@ -29,6 +29,21 @@
 
 -include_lib("eunit/include/eunit.hrl").
 
+%% @doc
+%% The Sophia-flavored 'Erlang representation' of on-chain data.
+%% Data is stored and manipulated on the chain without knowledge of Sophia
+%% types, which leads to a specialized representation that is confusing to
+%% manipulate directly. If you want to form contract arguments using an Erlang
+%% program, or pattern match the outputs of a contract call using an Erlang
+%% program, this Sophia-flavored representation is much more convenient. It
+%% de-anonymizes variant types and record types, and is more lenient in how it
+%% interprets a variety of cryptographic, binary, and string data types.
+%%
+%% When calling functions that manipulate this erlang representation, AACI type
+%% information representing the Sophia type of that term must be provided. The
+%% Sophia type used to produce that AACI type will determine what Erlang terms
+%% are actually accepted without producing errors.
+%%
 -type erlang_repr() ::   erlang_repr_int()
                        | erlang_repr_address()
                        | erlang_repr_contract()
@@ -43,19 +58,6 @@
                        | erlang_repr_tuple()
                        | erlang_repr_variant()
                        | erlang_repr_record().
-% The Sophia-flavored 'Erlang representation' of on-chain data.
-% Data is stored and manipulated on the chain without knowledge of Sophia
-% types, which leads to a specialized representation that is confusing to
-% manipulate directly. If you want to form contract arguments using an Erlang
-% program, or pattern match the outputs of a contract call using an Erlang
-% program, this Sophia-flavored representation is much more convenient. It
-% de-anonymizes variant types and record types, and is more lenient in how it
-% interprets a variety of cryptographic, binary, and string data types.
-%
-% When calling functions that manipulate this erlang representation, AACI type
-% information representing the Sophia type of that term must be provided. The
-% Sophia type used to produce that AACI type will determine what Erlang terms
-% are actually accepted without producing errors.
 
 
 %-type erlang_repr() ::   integer()
@@ -66,308 +68,305 @@
                        %| [erlang_repr()]
                        %| #{erlang_repr() => erlang_repr()}.
 
+%% @doc
+%% The Erlang representation of a Sophia `int`
+%% Integers will be used as-is. Strings will be parsed using list_to_integer/1.
+%% fate_to_erlang/2 always produces the integer representation.
 
 -type erlang_repr_int() :: integer() | string().
-% The Erlang representation of a Sophia `int'
-% Integers will be used as-is. Strings will be parsed using `list_to_integer/1'.
-% `fate_to_erlang/2' always produces the integer representation.
 
+%% @doc
+%% The Erlang representation of a Sophia `address`
+%% This can either be the "ak_..." string produced by gmserialization,
+%% GajuDesk, etc. or a 'raw' binary of 32 bytes. fate_to_erlang/2 always
+%% produces the "ak_..." string as an Erlang list. The Sophia-flavored Erlang
+%% representation should not be used if this is undesirable.
 
 -type erlang_repr_address() :: unicode:chardata() | {raw, <<_:32*8>>}.
-% The Erlang representation of a Sophia `address'
-% This can either be the `"ak_..."' string produced by gmserialization,
-% GajuDesk, etc. or a 'raw' binary of 32 bytes. `fate_to_erlang/2' always
-% produces the `"ak_..."' string as an Erlang list. The Sophia-flavored Erlang
-% representation should not be used if this is undesirable.
 
+%% @doc
+%% The Erlang representation of a Sophia `contract`
+%% This can either be the "ct_..." string produced by gmserialization,
+%% GajuDesk, etc. or a 'raw' binary of 32 bytes. fate_to_erlang/2 always
+%% produces the "ct_..." string as an Erlang list.
 
 -type erlang_repr_contract() :: unicode:chardata() | {raw, <<_:32*8>>}.
-% The Erlang representation of a Sophia `contract'
-% This can either be the `"ct_..."' string produced by gmserialization,
-% GajuDesk, etc. or a 'raw' binary of 32 bytes. fate_to_erlang/2 always
-% produces the `"ct_..."' string as an Erlang list.
 
+%% @doc
+%% The Erlang representation of a Sophia `signature`
+%% This can either be the "sg_..." string produced by gmserialization,
+%% GajuDesk, etc. or a 'raw' binary of 64 bytes. (Not 32.) Unlike addresses and
+%% contracts, 'raw' binaries can be wrapped or unwrapped when representing a
+%% signature. fate_to_erlang/2 always produces the "sg_..." string as an Erlang
+%% list.
 
 -type erlang_repr_signature() :: unicode:chardata() | <<_:64*8>> | {raw, <<_:64*8>>}.
-% The Erlang representation of a Sophia `signature'
-% This can either be the `"sg_..."' string produced by gmserialization,
-% GajuDesk, etc. or a 'raw' binary of 64 bytes. (Not 32.) Unlike addresses and
-% contracts, 'raw' binaries can be wrapped or unwrapped when representing a
-% signature. fate_to_erlang/2 always produces the `"sg_..."' string as an Erlang
-% list.
 
+%% @doc
+%% The Erlang representation of a Sophia `bool`
+%% fate_to_erlang/2 always produces atoms, but erlang_to_fate/2 also accepts
+%% the lists "true" and "false".
 
 -type erlang_repr_bool() :: true | false | string().
-% The Erlang representation of a Sophia `bool'
-% `fate_to_erlang/2' always produces atoms, but `erlang_to_fate/2' also accepts
-% the lists `"true"' and `"false"'.
 
+%% @doc
+%% The Erlang representation of a Sophia `string`
+%% The conversion uses unicode:characters_to_binary/1, so a list, a UTF8
+%% binary, or an iolist mixing both are all acceptable inputs. fate_to_erlang/2
+%% always produces a list.
 
 -type erlang_repr_string() :: unicode:chardata().
-% The Erlang representation of a Sophia `string'
-% The conversion uses `unicode:characters_to_binary/1', so a list, a UTF8
-% binary, or an iolist mixing both are all acceptable inputs. `fate_to_erlang/2'
-% always produces a list.
 
+%% @doc
+%% The Erlang representation of a Sophia `char`
+%% On-chain a `char` means one unicode code point, and is just a FATE integer.
+%% fate_to_erlang/2 will provide this integer as-is, but erlang_to_fate/2 can
+%% be passed an arbitrary unicode string, as long as it decodes to a single
+%% unicode code point.
 
 -type erlang_repr_char() :: integer() | unicode:chardata().
-% The Erlang representation of a Sophia `char'
-% On-chain a `char' means one unicode code point, and is just a FATE integer.
-% `fate_to_erlang/2' will provide this integer as-is, but `erlang_to_fate/2' can
-% be passed an arbitrary unicode string, as long as it decodes to a single
-% unicode code point.
 
+%% @doc
+%% The Erlang representation of Sophia `bytes()`
+%% Sophia has fixed-length `bytes(10)` etc. and variable length `bytes()`.
+%% These are treated the same in the Erlang representation, but
+%% erlang_to_fate/2 will check the length of the binary in the fixed length
+%% case, and provide errors if it doesn't agree.
 
 -type erlang_repr_bytes() :: binary().
-% The Erlang representation of Sophia `bytes()'
-% Sophia has fixed-length `bytes(10)' etc. and variable length `bytes()'.
-% These are treated the same in the Erlang representation, but
-% `erlang_to_fate/2' will check the length of the binary in the fixed length
-% case, and provide errors if it doesn't agree.
 
+%% @doc
+%% The Erlang representation of Sophia `bits()`
+%% FATE has a representation of bitstrings that one might call novel. A
+%% FATE/Sophia bitstring is actually represented as an integer, so there is no
+%% concept of bitstring 'length', all bitstrings have infinitely many leading
+%% zeroes, if the integer is positive, and, surprisingly, infinitely many
+%% leading ones, if the integer is negative! To represent this in the general
+%% case, erlang_to_fate/2 accepts arbitrary integers, positive or negative, and
+%% fate_to_erlang/2 always produces integers, but for convenience,
+%% erlang_to_fate/2 also accepts arbitrary Erlang bitstrings, which are
+%% converted into positive integers, i.e. '0 by default' FATE bitstrings.
 
 -type erlang_repr_bits() :: bitstring().
-% The Erlang representation of Sophia `bits()'
-% FATE has a representation of bitstrings that one might call novel. A
-% FATE/Sophia bitstring is actually represented as an integer, so there is no
-% concept of bitstring 'length', all bitstrings have infinitely many leading
-% zeroes, if the integer is positive, and, surprisingly, infinitely many
-% leading ones, if the integer is negative! To represent this in the general
-% case, `erlang_to_fate/2' accepts arbitrary integers, positive or negative, and
-% `fate_to_erlang/2' always produces integers, but for convenience,
-% `erlang_to_fate/2' also accepts arbitrary Erlang bitstrings, which are
-% converted into positive integers, i.e. '0 by default' FATE bitstrings.
 
+%% @doc
+%% The Erlang representation of a Sophia `list(_)`
+%% Simply a list. Each element of the list is converted forwards/backwards as
+%% normal.
 
 -type erlang_repr_list() :: [erlang_repr()].
-% The Erlang representation of a Sophia `list(_)'
-% Simply a list. Each element of the list is converted forwards/backwards as
-% normal.
 
+%% @doc
+%% The Erlang representation of a Sophia `map(_, _)`
+%% Simply a map. Each key and value is converted forwards/backwards as normal.
 
 -type erlang_repr_map() :: #{erlang_repr() => erlang_repr()}.
-% The Erlang representation of a Sophia `map(_, _)'
-% Simply a map. Each key and value is converted forwards/backwards as normal.
 
+%% @doc
+%% The Erlang representation of a Sophia tuple
+%% In Sophia these types are written `a * b`, `a * b * c`, and so on. Despite
+%% the binary infix notation, a product of more than two types gives a single
+%% tuple type with that many elements, so (1, 2, 3) is an int * int * int.
+%% gmbytecode requires FATE tuples to be wrapped in {tuple, {X, Y}}, etc. but
+%% the Erlang representation specifically requires that the tuple be provided
+%% without any wrappers, so {X, Y}, etc. These representations cannot be mixed,
+%% since at the highest level they are both just tuples. Each element of the
+%% tuple is also converted forwards/backwards as normal. Although FATE has
+%% singleton tuples, Sophia doesn't, so an ACI/AACI will never produce a
+%% singleton tuple in an interface; if your contract takes singleton tuples,
+%% these Sophia representations will probably still work, but you won't be able
+%% to generate the AACI that makes them work, so it is likely simpler to just
+%% use the FATE representation.
 
--type erlang_repr_tuple() :: {}
+-type erlang_repr_tuple() :: {} | {erlang_repr(), erlang_repr()} | tuple().
-                           | {erlang_repr(), erlang_repr()}
-                           | tuple().
-% The Erlang representation of a Sophia tuple
-% In Sophia these types are written `a * b', `a * b * c', and so on. Despite
-% the binary infix notation, a product of more than two types gives a single
-% tuple type with that many elements, so `(1, 2, 3)' is an `int * int * int'.
-% `gmbytecode' requires FATE tuples to be wrapped in `{tuple, {X, Y}}', etc. but
-% the Erlang representation specifically requires that the tuple be provided
-% without any wrappers, so `{X, Y}', etc. These representations cannot be mixed,
-% since at the highest level they are both just tuples. Each element of the
-% tuple is also converted forwards/backwards as normal. Although FATE has
-% singleton tuples, Sophia doesn't, so an ACI/AACI will never produce a
-% singleton tuple in an interface; if your contract takes singleton tuples,
-% these Sophia representations will probably still work, but you won't be able
-% to generate the AACI that makes them work, so it is likely simpler to just
-% use the FATE representation.
 
+%% @doc
+%% The Erlang representation of a Sophia ADT
+%% Sophia has a `datatype` keyword that allows the definition of algebraic data
+%% types, also known as variants, tagged unions, sum types, coproduct types,
+%% etc. In Erlang these are normally represented as an atom, or as a tuple
+%% whose first term is an atom, so for familiarity, erlang_to_fate/2 accepts
+%% lists in place of atoms, or tuples whose first term is a list. Note that
+%% constructors in Sophia have to be capitalized, so actual atoms wouldn't be
+%% that convenient. fate_to_erlang/2 always produces a tuple whose first term
+%% is a list, even if that tuple is a singleton. This allows the user to
+%% blindly call element(0) or tuple_to_list(_) without annoying special cases.
+%%
+%% Sophia also has a few built-in algebraic data types, for building its
+%% standard library, and for exposing certain FATE primitives, which will
+%% therefore also use this representation, e.g. "None", {"None"}, or
+%% {"Some", Datum} for the `option(_)` type.
 
--type erlang_repr_variant() :: string()
+-type erlang_repr_variant() :: string() | {string()} | {string(), erlang_repr()} | tuple().
-                             | {string()}
-                             | {string(), erlang_repr()}
-                             | tuple().
-% The Erlang representation of a Sophia ADT
-% Sophia has a `datatype' keyword that allows the definition of algebraic data
-% types, also known as variants, tagged unions, sum types, coproduct types,
-% etc. In Erlang these are normally represented as an atom, or as a tuple
-% whose first term is an atom, so for familiarity, `erlang_to_fate/2' accepts
-% lists in place of atoms, or tuples whose first term is a list. Note that
-% constructors in Sophia have to be capitalized, so actual atoms wouldn't be
-% that convenient. `fate_to_erlang/2' always produces a tuple whose first term
-% is a list, even if that tuple is a singleton. This allows the user to
-% blindly call `element(0)' or `tuple_to_list(_)' without annoying special cases.
-%
-% Sophia also has a few built-in algebraic data types, for building its
-% standard library, and for exposing certain FATE primitives, which will
-% therefore also use this representation, e.g. `"None"', `{"None"}', or
-% `{"Some", Datum}' for the `option(_)' type.
 
+%% @doc
+%% The Erlang representation of a Sophia record type
+%% Sophia has a `record` keyword, that allows the definition of new record
+%% types. Sophia records are meant to be reminiscent of Sophia maps, so in the
+%% Erlang representation of Sophia records, we use a map, with strings as keys,
+%% and arbitrary erlang_repr() terms as values.
 
 -type erlang_repr_record() :: #{string() => erlang_repr()}.
-% The Erlang representation of a Sophia record type
-% Sophia has a `record' keyword, that allows the definition of new record
-% types. Sophia records are meant to be reminiscent of Sophia maps, so in the
-% Erlang representation of Sophia records, we use a map, with strings as keys,
-% and arbitrary `erlang_repr()' terms as values.
 
+%% @doc
+%% The Accelerated Aeternity Contract Interface
+%% Sophia tooling was originally written around a javascript use-case, but
+%% hakuzaru is written for Erlang, so we don't really want to walk through big
+%% JSON trees every time we do an on-chain action, so the AACI exists to
+%% accelerate these actions, so that interacting with contract entrypoints from
+%% within a pure Erlang environment is convenient and fast.
+%%
+%% The layout may change, but an AACI basically consists of three parts:
+%% - The name of the contract,
+%% - The 'annotated' entrypoint specs, designed for fast conversion to/from
+%%   the representation used on-chain, see function_spec/0,
+%% - The 'opaque' type definitions, all the internal type aliases and
+%%   definitions within the contract and its imported namespaces.
 
 -type aaci() :: {aaci, string(), #{string() => function_spec()}, #{string() => typedef()}}.
-% The Accelerated Aeternity Contract Interface
-% Sophia tooling was originally written around a javascript use-case, but
-% hakuzaru is written for Erlang, so we don't really want to walk through big
-% JSON trees every time we do an on-chain action, so the AACI exists to
-% accelerate these actions, so that interacting with contract entrypoints from
-% within a pure Erlang environment is convenient and fast.
-%
-% The layout may change, but an AACI basically consists of three parts:
-% <ul>
-%  <li>The name of the contract,</li>
-%  <li>The 'annotated' entrypoint specs, designed for fast conversion to/from
-%   the representation used on-chain, see `function_spec/0',</li>
-%  <li>The 'opaque' type definitions, all the internal type aliases and
-%   definitions within the contract and its imported namespaces.</li>
-% </ul>
-
 
+%% @doc
+%% The fully annotated spec of a contract entrypoint, for fast call formation
+%% The first term is a list of parameter names and their types, as expected by
+%% erlang_args_to_fate/2, and the second term is a single type, as expected by
+%% fate_to_erlang/2. See annotated_type/0 for the details of how these types
+%% are represented and why, but for most purposes it is fine to just store and
+%% pass these type terms around without looking at their contents.
 -type function_spec() :: {[{string(), annotated_type()}], annotated_type()}.
-% The fully annotated spec of a contract entrypoint, for fast call formation
+%% @doc
-% The first term is a list of parameter names and their types, as expected by
+%% A fully annotated Sophia type
-% `erlang_args_to_fate/2', and the second term is a single type, as expected by
+%% Sophia allows for arbitrary nesting of type aliases, each with parameters,
-% `fate_to_erlang/2'. See annotated_type/0 for the details of how these types
+%% and each potentially substituting for another arbitrarily complex type
-% are represented and why, but for most purposes it is fine to just store and
+%% alias, so there is a potentially indefinite amount of work converting the
-% pass these type terms around without looking at their contents.
+%% type `my_type_alias` as it would appear in Sophia/in the ACI, into the
-
+%% actual variant/record/list/map/tuple type expression that it ultimately
+%% represents. To overcome this, we 'annotate' a type, recording what its
+%% aliased name was, along with its actual definition.
+%%
+%% Normally you can extract the annotated types from a function_spec(), and
+%% pass them into the conversion function that needs them, but it can also be
+%% useful to walk through the annotated types yourself. Confusingly, if you
+%% want to recursively descend down an annotated type, you want to recurse on
+%% the third element in the tuple, not the first two, as the first two
+%% represent incomplete levels of normalization, which can be more descriptive
+%% for users, but aren't as actionable as the fully normalized third element.
+%%
+%% Despite the third term being the most important, it is kept at the end,
+%% because that is what is most memorable, since each element of the triple is
+%% more normalized than the last, and because that is what is easiest to read,
+%% since the third term is usually an explosion of nested braces and brackets,
+%% making anything written after it basically unreadable.
+%%
+%% If you look at examples of annotated types produced in your own programs,
+%% you will tend to see things like {integer, alread_normalized, integer},
+%% making it even less clear that the third element is the important one, or
+%% why that is. For some fairly simple but informative examples, consider these
+%% type aliases:
+%%   contract C =
+%%     record my_record('t) = {x: 't, y: 't}
+%%     type my_alias1 = int
+%%     type my_alias2 = list(my_alias1)
+%%     type my_alias3 = my_record(my_alias1)
+%% If these type aliases appeared in a function spec, the AACI would represent
+%% them as the following annotated types:
+%%    {"my_alias1", integer, integer}
+%%    {"my_alias2", {list, ["my_alias1"]}, {list, [{"my_alias1", integer, integer}]}}
+%%    {"my_alias3", {"my_record", ["my_alias1"]}, {record, [{"x", {"my_alias1", integer, integer}}, {"y", {"my_alias1", integer, integer}}]}}
+%%
+%% The first term is the type roughly as it appeared in the ACI, see
+%% opaque_type/0 for more information.
+%%
+%% The second term is that same type but 'head normalized', chasing type
+%% aliases iteratively, until it is some built in type like an integer, or some
+%% user-defined record type or ADT. If the alias reduces to a list or map or
+%% tuple with more aliased types nested inside, these nested type
+%% subexpressions are not normalized any further, as the 'list' or 'map'
+%% connective is considered the 'head' of the type expression, and is
+%% normalized. Record type names and ADT names are not considered aliases, and
+%% so are considered head normalized, but both can take parameters, which can
+%% also stay un-normalized, as with lists or maps. If the head normalized type
+%% is the same as the opaque type, then the atom 'already_normalized' is placed
+%% instead, as a hint that instead of printing messages like
+%% "my_alias1 (i.e.  int)", a simple message like "list(my_record)" will do.
+%%
+%% The third term is the head normalized type with two changes, first, record
+%% and variant definitions are subtituted in as well, giving a list of field
+%% names or constructor names in full, and second, each subexpression is
+%% recursively annotated, meaning its opaque, head-normalized, and fully
+%% normalized parts also appear as triples.
 
 -type annotated_type() :: {opaque_type(), already_normalized | opaque_type(), annotated_type_body()}.
-% A fully annotated Sophia type.
-% Sophia allows for arbitrary nesting of type aliases, each with parameters,
-% and each potentially substituting for another arbitrarily complex type
-% alias, so there is a potentially indefinite amount of work converting the
-% type `my_type_alias' as it would appear in Sophia/in the ACI, into the
-% actual variant/record/list/map/tuple type expression that it ultimately
-% represents. To overcome this, we 'annotate' a type, recording what its
-% aliased name was, along with its actual definition.
-%
-% Normally you can extract the annotated types from a `function_spec()', and
-% pass them into the conversion function that needs them, but it can also be
-% useful to walk through the annotated types yourself. Confusingly, if you
-% want to recursively descend down an annotated type, you want to recurse on
-% the third element in the tuple, not the first two, as the first two
-% represent incomplete levels of normalization, which can be more descriptive
-% for users, but aren't as actionable as the fully normalized third element.
-%
-% Despite the third term being the most important, it is kept at the end,
-% because that is what is most memorable, since each element of the triple is
-% more normalized than the last, and because that is what is easiest to read,
-% since the third term is usually an explosion of nested braces and brackets,
-% making anything written after it basically unreadable.
-%
-% If you look at examples of annotated types produced in your own programs,
-% you will tend to see things like `{integer, alread_normalized, integer}',
-% making it even less clear that the third element is the important one, or
-% why that is. For some fairly simple but informative examples, consider these
-% type aliases:
-% <pre>
-%   contract C =
-%     record my_record('t) = {x: 't, y: 't}
-%     type my_alias1 = int
-%     type my_alias2 = list(my_alias1)
-%     type my_alias3 = my_record(my_alias1)
-% </pre>
-% If these type aliases appeared in a function spec, the AACI would represent
-% them as the following annotated types:
-% <pre>
-%    {"my_alias1", integer, integer}
-%    {"my_alias2", {list, ["my_alias1"]}, {list, [{"my_alias1", integer, integer}]}}
-%    {"my_alias3", {"my_record", ["my_alias1"]}, {record, [{"x", {"my_alias1", integer, integer}}, {"y", {"my_alias1", integer, integer}}]}}
-% </pre>
-%
-% The first term is the type roughly as it appeared in the ACI, see
-% opaque_type/0 for more information.
-%
-% The second term is that same type but 'head normalized', chasing type
-% aliases iteratively, until it is some built in type like an integer, or some
-% user-defined record type or ADT. If the alias reduces to a list or map or
-% tuple with more aliased types nested inside, these nested type
-% subexpressions are not normalized any further, as the 'list' or 'map'
-% connective is considered the 'head' of the type expression, and is
-% normalized. Record type names and ADT names are not considered aliases, and
-% so are considered head normalized, but both can take parameters, which can
-% also stay un-normalized, as with lists or maps. If the head normalized type
-% is the same as the opaque type, then the atom `already_normalized' is placed
-% instead, as a hint that instead of printing messages like
-% `my_alias1 (i.e.  int)', a simple message like `list(my_record)' will do.
-%
-% The third term is the head normalized type with two changes, first, record
-% and variant definitions are subtituted in as well, giving a list of field
-% names or constructor names in full, and second, each subexpression is
-% recursively annotated, meaning its opaque, head-normalized, and fully
-% normalized parts also appear as triples.
 
+%% @doc
+%% The primitive connectives that complex type expressions can be built out of.
+%% It takes a parameter, since builtin_type(opaque_type()),
+%% builtin_type(annotated_type()), and builtin_type(typedef_expression()) are
+%% all useful recursive applications of these connectives.
 
--type builtin_type(T) :: {bytes, [integer() | any]}
+-type builtin_type(T) ::   {bytes, [integer() | any]}
-                       | {tuple, [T]}
+                         | {tuple, [T]}
-                       | {list, [T]}
+                         | {list, [T]}
-                       | {map, [T]}
+                         | {map, [T]}
-                       | integer
+                         | integer
-                       | boolean
+                         | boolean
-                       | bits
+                         | bits
-                       | char
+                         | char
-                       | string
+                         | string
-                       | address
+                         | address
-                       | signature
+                         | signature
-                       | contract
+                         | contract
-                       | channel
+                         | channel
-                       | unknown_type.
+                         | unknown_type.
-% The primitive connectives that complex type expressions can be built out of.
-% It takes a parameter, since `builtin_type(opaque_type())',
-% `builtin_type(annotated_type())', and `builtin_type(typedef_expression())' are
-% all useful recursive applications of these connectives.
 
+%% @doc
+%% The connectives for defining new records and ADTs.
+%% Record types and ADTs can both appear in the original type definitions in
+%% the body of a contract, as well as in the recursively normalized 'annotated
+%% types' that the AACI stores. We use the same layout in both cases.
+-type user_defined_type(T) ::   {record, [{string(), T}]} | {variant, [{string(), [T]}]}.
 
--type user_defined_type(T) :: {record, [{string(), T}]}
+%% @doc
-                            | {variant, [{string(), [T]}]}.
+%% An opaque type as it originally appeared in a function spec.
-% The connectives for defining new records and ADTs.
+%% The Sophia compiler may have a different representation for these type
-% Record types and ADTs can both appear in the original type definitions in
+%% expressions, but we make a simple representation here as well.
-% the body of a contract, as well as in the recursively normalized 'annotated
+%% These type expressions are really function applications, in a limited sort
-% types' that the AACI stores. We use the same layout in both cases.
+%% of rewrite calculus without higher order functions. After performing some
-
+%% rewrites, the format actually stays the same, so the second term in a type
-
+%% triple is also this 'opaque type', but that is a coincidence; this type is
--type opaque_type() :: string()
+%% primarily designed to represent types that haven't been head-normalized at
-                     | {string(), [opaque_type()]}
+%% all % yet.
-                     | builtin_type(opaque_type()).
+-type opaque_type() :: string() | {string(), [opaque_type()]} | builtin_type(opaque_type()).
-% An opaque type as it originally appeared in a function spec.
-% The Sophia compiler may have a different representation for these type
-% expressions, but we make a simple representation here as well.
-% These type expressions are really function applications, in a limited sort
-% of rewrite calculus without higher order functions. After performing some
-% rewrites, the format actually stays the same, so the second term in a type
-% triple is also this 'opaque type', but that is a coincidence; this type is
-% primarily designed to represent types that haven't been head-normalized at
-% all % yet.
-
-
--type annotated_type_body() :: builtin_type(annotated_type())
-                             | user_defined_type(annotated_type()).
-% The recursively annotated part of an annotated type triple
-% This can be any anonymous type connective, with annotated types inside, or
-% it can be a record definition, with annotated types for fields, or it can be
-% an ADT definition, with annotated types for each constructor input.
-
-
--type typedef_expression() :: {var, string()}
-                            | string()
-                            | {string(), [typedef_expression()]}
-                            | builtin_type(typedef_expression()).
-% The recursive type expressions that can appear in the definitions of type aliases.
-% Similar to opaque_type(), but type aliases can take parameters as well,
-% which means those parameters can also appear anywhere within the recursive
-% type expression that defines the type alias.
 
+%% @doc
+%% The recursively annotated part of an annotated type triple
+%% This can be any anonymous type connective, with annotated types inside, or
+%% it can be a record definition, with annotated types for fields, or it can be
+%% an ADT definition, with annotated types for each constructor input.
+-type annotated_type_body() :: builtin_type(annotated_type()) | user_defined_type(annotated_type()).
 
+%% @doc
+%% The recursive type expressions that can appear in the definitions of type aliases.
+%% Similar to opaque_type(), but type aliases can take parameters as well,
+%% which means those parameters can also appear anywhere within the recursive
+%% type expression that defines the type alias.
+-type typedef_expression() ::   {var, string()}
+                              | string()
+                              | {string(), [typedef_expression()]}
+                              | builtin_type(typedef_expression()).
+%% @doc
+%% A type definition as it appears in the AACI.
+%% A type definition has a list of parameter names, and then some body defined
+%% using builtin type connectives, other defined types, and those parameters.
 -type typedef() :: {[string()], typedef_body()}.
-% A type definition as it appears in the AACI.
-% A type definition has a list of parameter names, and then some body defined
-% using builtin type connectives, other defined types, and those parameters.
-
-
--type typedef_body() :: typedef_expression()
-                      | user_defined_type(typedef_expression()).
-% The possible right-hand-sides of a type definition
-% A type definition means a type alias, a record definition, or an ADT
-% definition. Aliases are just some type expression, possibly with type
-% parameters, and records and variants are already defined above in
-% user_defined_type/1, with arbitrary type expressions in each one, but again,
-% they could contain type parameters as well.
-
 
+%% @doc
+%% The possible right-hand-sides of a type definition
+%% A type definition means a type alias, a record definition, or an ADT
+%% definition. Aliases are just some type expression, possibly with type
+%% parameters, and records and variants are already defined above in
+%% user_defined_type/1, with arbitrary type expressions in each one, but again,
+%% they could contain type parameters as well.
+-type typedef_body() :: typedef_expression() | user_defined_type(typedef_expression()).
 
 %%% ACI/AACI
 
@@ -390,6 +389,7 @@ prepare_from_file(Path) ->
 -spec prepare(ACI) -> AACI
     when ACI  :: term(),
          AACI :: aaci().
+
 %% @doc
 %% Convert the ACI structure produced by the compiler into the AACI format used by Hakuzaru
 %% See the documentation for the aaci/0 type for more information.
@@ -409,8 +409,8 @@ prepare(ACI) ->
     % make error messages easier to understand.
     InternalTypeDefs = maps:merge(builtin_typedefs(), TypeDefs),
     Specs = annotate_function_specs(OpaqueSpecs, InternalTypeDefs, #{}),
-    {aaci, Name, Specs, TypeDefs}.
 
+    {aaci, Name, Specs, TypeDefs}.
 
 -spec convert_aci_types(ACI) -> {Name, OpaqueSpecs, TypeDefs}
     when ACI         :: term(),
@@ -442,20 +442,17 @@ convert_aci_types(ACI) ->
     % just pre-compute and acceleration.
     {Name, Specs, TypeDefMap}.
 
-
 convert_function_spec(#{name := NameBin, arguments := Args, returns := Result}) ->
     Name = binary_to_list(NameBin),
     ArgTypes = lists:map(fun convert_arg/1, Args),
     ResultType = opaque_type([], Result),
     {Name, ArgTypes, ResultType}.
 
-
 convert_arg(#{name := NameBin, type := TypeDef}) ->
     Name = binary_to_list(NameBin),
     Type = opaque_type([], TypeDef),
     {Name, Type}.
 
-
 convert_namespace_typedefs(#{namespace := NS}) ->
     Name = namespace_name(NS),
     convert_typedefs(NS, Name);
@@ -489,14 +486,12 @@ convert_typedefs_loop([Next | Rest], NamePrefix, Converted) ->
     Def = opaque_type(Params, DefACI),
     convert_typedefs_loop(Rest, NamePrefix, [Converted, {Name, Params, Def}]).
 
-
 -spec collect_opaque_types(Tree, TypeDefs) -> TypeDefs
     when Tree     :: typedef_tree(),
          TypeDefs :: #{string() => typedef()}.
 
 -type typedef_tree() :: {string(), [string()], typedef_body()} | list(typedef_tree()).
 
-
 collect_opaque_types([], Types) ->
     Types;
 collect_opaque_types([L | R], Types) ->
@@ -505,17 +500,15 @@ collect_opaque_types([L | R], Types) ->
 collect_opaque_types({Name, Params, Def}, Types) ->
     maps:put(Name, {Params, Def}, Types).
 
-
-
 %%% ACI Type -> Opaque Type
 
 -spec opaque_type(Params, ACIType) -> Opaque
     when Params  :: [string()],
          ACIType :: binary() | map(),
          Opaque  :: opaque_type().
+
 % Convert an ACI type defintion/spec into the 'opaque type' representation that
 % our dereferencing algorithms can reason about.
-
 opaque_type(Params, NameBin) when is_binary(NameBin) ->
     Name = opaque_type_name(NameBin),
     case not is_atom(Name) and lists:member(Name, Params) of
@@ -541,11 +534,10 @@ opaque_type(Params, Pair) when is_map(Pair) ->
     [{Name, TypeArgs}] = maps:to_list(Pair),
     {opaque_type_name(Name), [opaque_type(Params, Arg) || Arg <- TypeArgs]}.
 
-
 -spec opaque_type_name(binary()) -> atom() | string().
+
 % Atoms for any builtins that aren't qualified by a namespace in Sophia.
 % Everything else stays as a string, user-defined or not.
-
 opaque_type_name(<<"int">>)       -> integer;
 opaque_type_name(<<"bool">>)      -> boolean;
 opaque_type_name(<<"bits">>)      -> bits;
@@ -561,7 +553,6 @@ opaque_type_name(<<"map">>)       -> map;
 opaque_type_name(<<"channel">>)   -> channel;
 opaque_type_name(Name)            -> binary_to_list(Name).
 
-
 builtin_typedefs() ->
     #{"unit" => {[], {tuple, []}},
       "void" => {[], {variant, []}},
@@ -619,15 +610,14 @@ builtin_typedefs() ->
       "MCL_BLS12_381.fp" => {[], {bytes, [48]}}
      }.
 
-
 %%% Opaque Type -> Accelerated 'Annotated' Type
 
 % Type preparation has two goals. First, we need a data structure that can be
 % traversed quickly, to take sophia-esque erlang expressions and turn them into
 % fate-esque erlang expressions that gmbytecode can serialize. Second, we need
 % partially substituted names, so that error messages can be generated for why
-% "foobar" is not valid as the third field of a `bazquux', because the third
+% "foobar" is not valid as the third field of a `bazquux`, because the third
-% field is supposed to be `option(integer)', not `string'.
+% field is supposed to be `option(integer)`, not `string`.
 %
 % To achieve this we need three representations of each type expression, which
 % together form an 'annotated type'. First, we need the fully opaque name,
@@ -643,7 +633,7 @@ builtin_typedefs() ->
 %
 % In a lot of cases the opaque type given will already be normalized, in which
 % case either the normalized field or the non-normalized field of an annotated
-% type can simple be the atom `already_normalized', which means error messages
+% type can simple be the atom `already_normalized`, which means error messages
 % can simply render the normalized type expression and know that the error will
 % make sense.
 
@@ -665,7 +655,6 @@ annotate_function_specs([{Name, ArgsOpaque, ResultOpaque} | Rest], Types, Specs)
     NewSpecs = maps:put(Name, {Args, Result}, Specs),
     annotate_function_specs(Rest, Types, NewSpecs).
 
-
 -spec annotate_type(Opaque, Types) -> {ok, Annotated}
     when Opaque    :: opaque_type(),
          Types     :: #{string() => typedef()},
@@ -708,7 +697,6 @@ annotate_type_subexpressions({T, ElemsOpaque}, Types) ->
     {ok, Elems} = annotate_types(ElemsOpaque, Types, []),
     {ok, {T, Elems}}.
 
-
 -spec annotate_bindings(Bindings, Types, Acc) -> {ok, Annotated}
     when Bindings  :: [{string(), opaque_type()}],
          Types     :: #{string() => typedef()},
@@ -727,7 +715,6 @@ annotate_variants([{Name, Elems} | Rest], Types, Acc) ->
 annotate_variants([], _Types, Acc) ->
     {ok, lists:reverse(Acc)}.
 
-
 % This function evaluates type aliases in a loop, until eventually a usable
 % definition is found.
 normalize_opaque_type(T, Types) -> normalize_opaque_type(T, Types, true).
@@ -822,8 +809,6 @@ substitute_opaque_types(Bindings, Types) ->
     Each = fun(Type) -> substitute_opaque_type(Bindings, Type) end,
     lists:map(Each, Types).
 
-
-
 %%% Erlang to FATE
 
 -spec erlang_args_to_fate(VarTypes, Terms) -> {ok, FATE} | {error, Errors}
@@ -833,15 +818,15 @@ substitute_opaque_types(Bindings, Types) ->
          Errors   :: [{Reason, [PathStep]}],
          Reason   :: term(),
          PathStep :: term().
+
 %% @doc
 %% Call erlang_to_fate/2 on a list of named values.
-%% See the documentation for the `erlang_repr/0' type for more information on the
+%% See the documentation for the erlang_repr/0 type for more information on the
 %% format required.
-%%
+%% This is mainly used by hz.erl to form contract calls. The parameter names
-%% This is mainly used by `hz' to form contract calls. The parameter names
 %% and parameter types are provided in one zipped list, exactly as they appear
 %% in the AACI datatype, and then a second list of concrete arguments are
-%% provided in the format that `erlang_to_fate/2' expects. The parameter names
+%% provided in the format that erlang_to_fate/2 expects. The parameter names
 %% are used to provide slightly more informative errors.
 
 erlang_args_to_fate(VarTypes, Terms) ->
@@ -853,7 +838,6 @@ erlang_args_to_fate(VarTypes, Terms) ->
         DefLength   < ArgLength -> {error, too_many_args}
     end.
 
-
 -spec erlang_to_fate(Type, Erlang) -> {ok, FATE} | {error, Errors}
     when Type     :: annotated_type(),
          FATE     :: gmb_fate_data:fate_type(),
@@ -861,6 +845,7 @@ erlang_args_to_fate(VarTypes, Terms) ->
          Errors   :: [{Reason, [PathStep]}],
          Reason   :: term(),
          PathStep :: term().
+
 %% @doc
 %% Convert one Sophia-flavored Erlang term into one FATE-flavored Erlang terms.
 %% This is not usually used on its own, since if you need to form a contract
@@ -1214,7 +1199,6 @@ combine_errors(Broken) ->
     lists:foldl(F, [], Broken).
 
 
-
 %%% FATE to Erlang
 
 % Not sure if this is needed... fate_to_erlang shouldn't fail.
@@ -1223,7 +1207,6 @@ coerce_direction(Type, Term, to_fate) ->
 coerce_direction(Type, Term, from_fate) ->
     fate_to_erlang(Type, Term).
 
-
 -spec fate_to_erlang(Type, FATE) -> {ok, Erlang} | {error, Errors}
     when Type     :: annotated_type(),
          FATE     :: gmb_fate_data:fate_type(),
@@ -1231,12 +1214,13 @@ coerce_direction(Type, Term, from_fate) ->
          Errors   :: [{Reason, [PathStep]}],
          Reason   :: term(),
          PathStep :: term().
+
 %% @doc
 %% Convert a FATE-flavored Erlang term into a Sophia-flavored Erlang term
 %% Typically this is called by hakuzaru for you when decoding results from the
-%% chain, if you ask for the `erlang' format, but you can call this function
+%% chain, if you ask for the 'erlang' format, but you can call this function
-%% manually if you have a result in the `fate' format, and need the `erlang'
+%% manually if you have a result in the 'fate' format, and need the 'erlang'
-%% format now. See the documentation of the `erlang_repr/0' type for more
+%% format now. See the documentation of the erlang_repr/0 type for more
 %% information.
 
 fate_to_erlang({_, _, integer}, S) when is_integer(S) ->
@@ -1319,7 +1303,6 @@ opaque_type_to_iolist(N, _) ->
     io_lib:format("type ~p", [N]).
 
 
-
 %%% AACI Getters
 
 -spec get_function_signature(AACI, Fun) -> {ok, Type} | {error, Reason}
@@ -1327,13 +1310,14 @@ opaque_type_to_iolist(N, _) ->
          Fun    :: binary() | string(),
          Type   :: {term(), term()}, % FIXME
          Reason :: bad_fun_name.
+
 %% @doc
 %% Extract the type information for a particular function from the AACI
 %% If you want to manually convert a FATE result into the Sophia-flavored
 %% Erlang representation, or manually convert some or all of the inputs for a
 %% contract call yourself, this function gives you all of the annotated types
 %% associated with a contract entrypoint. For more information, see the
-%% documentation for the `annotated_type/0' type.
+%% documentation for the annotated_type/0 type.
 
 get_function_signature({aaci, _, FunDefs, _}, Fun) ->
     case maps:find(Fun, FunDefs) of

src/hz_fetcher.erl

@@ -1,13 +1,5 @@
-%%% @private
-%%% Hakuzaru Request Fetcher
-%%%
-%%% This module defines the request workers.
-%%% Each request to a remote chain node is handled by a worker that is spawned
-%%% to handle it and terminates on completion.
-%%% @end
-
 -module(hz_fetcher).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Craig Everett <ceverett@tsuriai.jp>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
 -license("MIT").

src/hz_format.erl

@@ -21,7 +21,7 @@
 %%% @end
 
 -module(hz_format).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Craig Everett <ceverett@tsuriai.jp>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
 -license("GPL-3.0-or-later").
@@ -462,26 +462,9 @@ ranks(heresy) ->
     ["k ", "m ", "b ", "t ", "q ", "e ", "z ", "y ", "r ", "Q "].
 
 
--spec mark(Unit) -> Mark
-    when Unit :: gaju | puck,
-         Mark :: $木 | $本.
-%% @doc
-%% Retrieve the unicode codepoint for the `gaju' mark (木) or the `puck' mark (本).
-
 mark(gaju) -> $木;
 mark(puck) -> $本.
 
-
--spec one(Unit) -> Pucks
-    when Unit  :: gaju | puck,
-         Pucks :: 1_000_000_000_000_000_000 | 1.
-%% @doc
-%% Quickly resolve the number of pucks in a given unit.
-%%
-%% The number of pucks in a gaju is so large that it can be a little bit annoying
-%% to remember the exact amount. This is a helper to simplify this when writing
-%% an app against the hakuzaru library when dealing in either unit.
-
 one(gaju) -> 1_000_000_000_000_000_000;
 one(puck) -> 1.
 

src/hz_grids.erl

@@ -37,7 +37,7 @@
 %%% @end
 
 -module(hz_grids).
--vsn("0.9.2").
+-vsn("0.9.1").
 -export([url/2, url/3, url/4, parse/1, req/2, req/3, req/4]).
 
 
@@ -47,7 +47,7 @@
          Result      :: {ok, GRIDS} | uri_string:uri_error(),
          GRIDS       :: uri_string:uri_string().
 %% @doc
-%% Takes an instruction and an HTTP endpoint location and forms a GRIDS URL.
+%% Takes 
 
 url(Instruction, HTTP) ->
     case uri_string:parse(HTTP) of
@@ -134,8 +134,6 @@ qwargs(Amount, Payload) ->
          Amount      :: non_neg_integer(),
          Payload     :: binary(),
          URL         :: string().
-%% @doc
-%% Translate a GRIDS URL into an Erlang terms instruction.
 
 parse(GRIDS) ->
     case uri_string:parse(GRIDS) of
@@ -192,43 +190,13 @@ l_to_i(S) ->
     end.
 
 
--spec req(Type, Message) -> Format
-    when Type    :: sign | tx | ack,
-         Message :: string() | binary(),
-         Format  :: map().
-%% @doc
-%% @equiv req(Type, Message, false)
-
 req(Type, Message) ->
     req(Type, Message, false).
 
-
--spec req(Type, Message, ID) -> Format
-    when Type    :: sign | tx | ack,
-         Message :: string() | binary(),
-         ID      :: false | string() | binary(),
-         Format  :: map().
-%% @doc
-%% Creates a GRIDS message format with the current `NetworkID'.
-%%
-%% The `ID' parameter indicates which key the requestee should sign with or
-%% is `false' to indicate that which key to sign with is up to the requestee.
-%% @equiv req(Type, Message, ID, CurrentNetworkID)
-
 req(Type, Message, ID) ->
     {ok, NetworkID} = hz:network_id(),
     req(Type, Message, ID, NetworkID).
 
-
--spec req(Type, Message, ID, NetworkID) -> Format
-    when Type      :: sign | tx | ack,
-         Message   :: string() | binary(),
-         ID        :: false | string() | binary(),
-         NetworkID :: string() | binary(),
-         Format    :: map().
-%% @doc
-%% Creates a GRIDS message format.
-
 req(sign, Message, ID, NetworkID) ->
     #{"grids"      => 1,
       "chain"      => "gajumaru",

src/hz_key_master.erl

@@ -1,43 +1,17 @@
 %%% @doc
-%%% Hakuzaru Key Functions
+%%% Key functions
 %%%
-%%% The Gajumaru's default key type is based on Elliptical Curve Cryptography (ECC).
+%%% The main reason this is a module of its own is that in the original architecture
-%%% The specific curve used is 25519, and the typical key representation is Ed25519.
+%%% it was a process rather than just a library of functions. Now that it exists, though,
-%%%
+%%% there is little motivation to cram everything here into the controller process's
-%%% The "Ed" in "Ed25519" stands for Harold Edwards. This form represents
+%%% code.
-%%% a coordinate on a "Twisted Edwards Curve".
-%%%
-%%% The "X" in "X25519" stands for the X-coordinate, also known as the
-%%% "Montgomery u-coordinate" on a "Montgomery Curve".
-%%%
-%%% The two are equivalent, but have meaningfully different properties.
 %%% @end
 
 -module(hz_key_master).
--vsn("0.9.2").
+-vsn("0.9.1").
 
--export([make_key/0, make_key/1, encode/1, decode/1]).
+-export([make_key/1, encode/1, decode/1]).
--export([shared_secret_a/6, shared_secret_b/6,
+-export([lcg/1]).
-         ed25519_pk_to_x25519/1, ed25519_sk_to_x25519/1,
-         hkdf/4, hkdf/5]).
-
-
--spec make_key() -> {ID, KeyPair}
-    when ID      :: string(),
-         KeyPair :: #{secret => binary(), public => binary()}.
-%% @doc
-%% @equiv make_key(<<>>)
-
-make_key() ->
-    make_key(<<>>).
-
-
--spec make_key(Secret) -> {ID, KeyPair}
-    when Secret  :: <<>> | <<_:32*8>>,
-         ID      :: string(),
-         KeyPair :: #{secret => binary(), public => binary()}.
-%% @doc
-%% Generate a Ed25519 keypair tagged with the corresponding Gajumaru ID.
 
 make_key(<<>>) ->
     Pair = #{public := Public} = ecu_eddsa:sign_keypair(),
@@ -151,212 +125,28 @@ sumcheck(Width, Bits) ->
     end.
 
 
--spec shared_secret_a(A_E_E_SK, B_P_E_PK, B_E_E_PK, Protocol, Version, Salt) -> SS
+
-    when A_E_E_SK :: binary(),
+-spec lcg(integer()) -> integer().
-         B_P_E_PK :: <<_:32*8>>,
+%% A simple PRNG that fits into 32 bits and is easy to implement anywhere (Kotlin).
-         B_E_E_PK :: <<_:32*8>>,
+%% Specifically, it is a "linear congruential generator" of the Lehmer variety.
-         Protocol :: binary(),
+%% The constants used are based on recommendations from Park, Miller and Stockmeyer:
-         Version  :: binary(),
+%% https://www.firstpr.com.au/dsp/rand31/p105-crawford.pdf#page=4
-         Salt     :: binary(),
-         SS       :: <<_:32*8>>.
-%% @doc
-%% Alice's side of a shared key derivation based on ed25519 keys as generated by this module.
 %%
-%% Typically Alice would be providing an ephemeral key to establish
+%% The input value should be between 1 and 2^31-1.
-%% a shared secret while remaining (at least initially) anonymous from Bob. Bob,
-%% on the other hand, is providing a permanent key and also an ephemeral key,
-%% proving identity without exposing the shared secret in the future were one of
-%% the secrets to be compromised.
-%% <ul>
-%%  <li>`A_E_E_SK' Alice's Ephemeral Ed25519 Secret Key.</li>
-%%  <li>`B_P_E_PK' Bob's Permanent Ed25519 Public Key.</li>
-%%  <li>`B_E_E_PK' Bob's Ephemeral Ed25519 Public Key.</li>
-%%  <li>`Protocol' is an arbitrary binary string, typically a protocol name in UTF-8.</li>
-%%  <li>`Version' is another arbitrary binary string, typically a protocol version in UTF-8.</li>
-%%  <li>`Salt' is a binary salt, which if empty will be replaced by a binary string of zeroes.</li>
-%%  <li>`SS' is the resulting 32-byte shared secret.</li>
-%% </ul>
-
-shared_secret_a(A_E_E_SK, B_P_E_PK, B_E_E_PK, Protocol, Version, Salt) ->
-    A_E_X_SK = ed25519_sk_to_x25519(A_E_E_SK),
-    B_P_X_PK = ed25519_pk_to_x25519(B_P_E_PK),
-    B_E_X_PK = ed25519_pk_to_x25519(B_E_E_PK),
-    DH_Permanent = crypto:compute_key(ecdh, B_P_X_PK, A_E_X_SK, x25519),
-    DH_Ephemeral = crypto:compute_key(ecdh, B_E_X_PK, A_E_X_SK, x25519),
-    finalize_hkdf(DH_Permanent, DH_Ephemeral, Protocol, Version, Salt).
-
-
--spec shared_secret_b(B_P_E_SK, B_E_E_SK, A_E_E_PK, Protocol, Version, Salt) -> SS
-    when B_P_E_SK :: binary(),
-         B_E_E_SK :: binary(),
-         A_E_E_PK :: <<_:32*8>>,
-         Protocol :: binary(),
-         Version  :: binary(),
-         Salt     :: binary(),
-         SS       :: <<_:32*8>>.
-%% @doc
-%% Bobs's side of a shared key derivation based on ed25519 keys as generated by this module.
 %%
-%% Typically Alice would be providing an ephemeral key to establish
+%% The purpose of this PRNG is for password-based dictionary shuffling.
-%% a shared secret while remaining (at least initially) anonymous from Bob. Bob,
-%% on the other hand, is providing a permanent key and also an ephemeral key,
-%% proving identity without exposing the shared secret in the future were one of
-%% the secrets to be compromised.
-%% <ul>
-%%  <li>`B_P_E_SK' Bob's Permanent Ed25519 Secret Key.</li>
-%%  <li>`B_E_E_SK' Bob's Ephemeral Ed25519 Secret Key.</li>
-%%  <li>`A_E_E_PK' Alice's Ephemeral Ed25519 Public Key.</li>
-%%  <li>`Protocol' is an arbitrary binary string, typically a protocol name in UTF-8.</li>
-%%  <li>`Version' is another arbitrary binary string, typically a protocol version in UTF-8.</li>
-%%  <li>`Salt' is a binary salt, which if empty will be replaced by a binary string of zeroes.</li>
-%%  <li>`SS' is the resulting 32-byte shared secret.</li>
-%% </ul>
 
-shared_secret_b(B_P_E_SK, B_E_E_SK, A_E_E_PK, Protocol, Version, Salt) ->
+lcg(N) ->
-    B_P_X_SK = ed25519_sk_to_x25519(B_P_E_SK),
+    M = 16#7FFFFFFF,
-    B_E_X_SK = ed25519_sk_to_x25519(B_E_E_SK),
+    A = 48271,
-    A_E_X_PK = ed25519_pk_to_x25519(A_E_E_PK),
+    Q = 44488,  %  M div A
-    DH_Permanent = crypto:compute_key(ecdh, A_E_X_PK, B_P_X_SK, x25519),
+    R = 3399,   %  M rem A
-    DH_Ephemeral = crypto:compute_key(ecdh, A_E_X_PK, B_E_X_SK, x25519),
+    Div = N div Q,
-    finalize_hkdf(DH_Permanent, DH_Ephemeral, Protocol, Version, Salt).
+    Rem = N rem Q,
-
+    S = Rem * A,
-finalize_hkdf(DH_Permanent, DH_Ephemeral, Protocol, Version, Salt) ->
+    T = Div * R,
-    MixedInput = <<DH_Permanent/binary, DH_Ephemeral/binary>>,
+    Result = S - T,
-    Info       = <<Protocol/binary, ":", Version/binary, ":">>,
+    case Result < 0 of
-    hkdf(sha256, MixedInput, Salt, Info).
+        false -> Result;
-
+        true  -> Result + M
-
-%% Curve25519 Prime Field Constant: 2^255 - 19
-%% Yes, in hex it reads kind of like "lucky fed"
-p() -> 16#7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED.
-
-
--spec ed25519_pk_to_x25519(ED25519_PubKey) -> X25519_PubKey
-    when ED25519_PubKey :: <<_:32*8>>,
-         X25519_PubKey  :: <<_:32*8>>.
-%% @doc
-%% Convert a curve 25519 public key from Edwards representation to X-coordinate
-%% representation.
-
-ed25519_pk_to_x25519(<<ED25519_PK:32/binary>>) ->
-    <<CompressedInt:256/little-integer>> = ED25519_PK,
-    % Clear the sign bit (MSB) to get the raw y-coordinate
-    Y = CompressedInt band ((1 bsl 255) - 1),
-
-    % Compute u = (1 + y) / (1 - y) mod P
-    Num = (1 + Y) rem p(),
-    Den = (1 - Y + p()) rem p(),
-    case Den =:= 0 of
-        true -> 
-            % If y == 1, the point maps to the point at infinity.
-            % On X25519, this translates to u = 0.
-            <<0:256/little-integer>>;
-        false ->
-            U = (Num * mod_inv(Den, p())) rem p(),
-            <<U:256/little-integer>>
     end.
-
-
--spec ed25519_sk_to_x25519(ED25519_SecKey) -> X25519_SecKey
-    when ED25519_SecKey :: binary(),
-         X25519_SecKey  :: <<_:32*8>>.
-%% @doc
-%% Convert a curve 25519 secret key from Edwards representation to X-coordinate
-%% representation.
-
-ed25519_sk_to_x25519(<<ED25519_SK_Secret:32/binary, _/binary>>) ->
-    <<X25519_SK:32/binary, _/binary>> = crypto:hash(sha512, ED25519_SK_Secret),
-    X25519_SK.
-
-mod_inv(A, M) ->
-    {1, X, _} = ext_gcd(A, M),
-    (X + M) rem M.
-
-ext_gcd(A, 0) ->
-    {A, 1, 0};
-ext_gcd(A, B) ->
-    {G, X1, Y1} = ext_gcd(B, A rem B),
-    {G, Y1, X1 - (A div B) * Y1}.
-
-
--spec hkdf(Hash, IKM, Salt, Info) -> DerivedKey
-    when Hash       :: md5 | sha | sha224 | sha256 | sha384 | sha512,
-         IKM        :: binary(),
-         Salt       :: binary(),
-         Info       :: binary(),
-         DerivedKey :: <<_:32*8>>.
-%% @doc
-%% 32-byte HMAC-Based Extract-and-Expand Key Derivation
-%% @equiv hkdf(Hash, IKM, Salt, Info, 32)
-
-hkdf(Hash, IKM, Salt, Info) ->
-    hkdf(Hash, IKM, Salt, Info, 32).
-
-
--spec hkdf(Hash, IKM, Salt, Info, Length) -> DerivedKey
-    when Hash       :: md5 | sha | sha224 | sha256 | sha384 | sha512,
-         IKM        :: binary(),
-         Salt       :: binary(),
-         Info       :: binary(),
-         Length     :: 16 | 20 | 28 | 32 | 48 | 64,
-         DerivedKey :: binary().
-%% @doc
-%% RFC-5869 compliant HMAC-Based Extract-and-Expand Key Derivation
-%%
-%% RFC-5869:
-%% <a href="https://datatracker.ietf.org/doc/html/rfc5869">https://datatracker.ietf.org/doc/html/rfc5869</a>
-%%
-%% The purpose of HKDF is to take an initial, raw secret input that might
-%% be mathematically strong but structurally "clumpy" and transform it into one
-%% or more uniform, high-entropy keys suitable for use in cryptography.
-%% 
-%% The problem is that when Alice and Bob compute a Diffie-Hellman shared secret
-%% over X25519, the resulting bytes are mathematically secure, but they are not
-%% evenly distributed as random noise. Cryptographic ciphers expect keys where
-%% every single bit has an exactly 50% chance of being a 0 or a 1. Passing raw
-%% DH outputs straight into a cipher can introduce subtle, exploitable patterns.
-%%
-%% HKDF "smooths out" the entropy.
-%%
-%% HMAC stands for "Keyed-Hash Message Authentication Code", but without the
-%% leading "K" just to keep us on our toes. The problem it solves is that simply
-%% concatenating a secret and some target data and hashing them together to produce
-%% a message authentication hash leaves the resulting hash vulnerable to a "length
-%% extension attack". An attacker can append additional data to the end of the
-%% message and arrive at a valid new hash without ever knowing the secret.
-%%
-%% RFC-2104 provides good background information on the technique:
-%% <a href="https://datatracker.ietf.org/doc/html/rfc2104">https://datatracker.ietf.org/doc/html/rfc2104</a>
-
-hkdf(Hash, IKM, Salt, Info, Length) ->
-    PRK = extract(Hash, Salt, IKM),
-    expand(Hash, PRK, Info, Length).
-
-extract(Hash, <<>>, IKM) ->
-    %% If salt is empty RFC 5869 requires a string of zeros equal to hash size
-    Salt = binary:copy(<<0>>, hash_size(Hash)),
-    extract(Hash, Salt, IKM);
-extract(Hash, Salt, IKM) ->
-    crypto:mac(hmac, Hash, Salt, IKM).
-
-expand(Hash, PRK, Info, OutLen) ->
-    HashLen = hash_size(Hash),
-    BlockCount = (OutLen + HashLen - 1) div HashLen,
-    true = BlockCount =< 255,
-    FullBlocks = expand_loop(Hash, PRK, Info, BlockCount, 1, <<>>, <<>>),
-    <<Output:OutLen/binary, _/binary>> = FullBlocks,
-    Output.
-
-expand_loop(Hash, PRK, Info, N, Counter, PrevT, Acc) when Counter =< N ->
-    Payload = <<PrevT/binary, Info/binary, Counter:8>>,
-    T = crypto:mac(hmac, Hash, PRK, Payload),
-    expand_loop(Hash, PRK, Info, N, Counter + 1, T, <<Acc/binary, T/binary>>);
-expand_loop(_, _, _, _, _, _, Acc) ->
-    Acc.
-
-hash_size(md5)    -> 16;
-hash_size(sha)    -> 20;
-hash_size(sha224) -> 28;
-hash_size(sha256) -> 32;
-hash_size(sha384) -> 48;
-hash_size(sha512) -> 64.

src/hz_man.erl

@@ -9,7 +9,7 @@
 %%% @end
 
 -module(hz_man).
--vsn("0.9.2").
+-vsn("0.9.1").
 -behavior(gen_server).
 -author("Craig Everett <ceverett@tsuriai.jp>").
 -copyright("Craig Everett <ceverett@tsuriai.jp>").
@@ -172,6 +172,7 @@ start_link() ->
 %% preparatory work necessary for proper function.
 
 init(none) ->
+    ok = io:format("hz_man starting.~n"),
     State = #s{},
     {ok, State}.
 

src/hz_sophia.erl

@@ -1,5 +1,5 @@
 -module(hz_sophia).
--vsn("0.9.2").
+-vsn("0.9.1").
 -author("Jarvis Carroll <spiveehere@gmail.com>").
 -copyright("Jarvis Carroll <spiveehere@gmail.com>").
 -license("GPL-3.0-or-later").
@@ -53,7 +53,7 @@ parse_literal2(Result, Pos, String) ->
 
 %% @doc
 %% Parse an untyped Sophia expression into a FATE term
-%% Like `parse_literal/2', but will not produce type errors. This function can
+%% Like parse_literal/2, but will not produce type errors. This function can
 %% still produce parsing errors, and can produce errors when variants or
 %% records are encountered, since they can't be parsed unless you have type
 %% information.
@@ -67,7 +67,6 @@ parse_literal2(Result, Pos, String) ->
 parse_literal(String) ->
     parse_literal(unknown_type(), String).
 
-
 %%% Tokenizer
 
 -define(IS_LATIN_UPPER(C), (((C) >= $A) and ((C) =< $Z))).
@@ -253,8 +252,6 @@ escape_char($\") -> "\\\"";
 escape_char($\\) -> "\\\\";
 escape_char(I) -> I.
 
-
-
 %%% Sophia Literal Parser
 
 %%% This parser is a simple recursive descent parser, written explicitly in
@@ -964,7 +961,7 @@ wrap_error(Reason, _) -> Reason.
 %% integers, and strings, but it will misinterpret the types of records and
 %% unicode characters, and will crash the process if variants are encountered.
 %%
-%% `fate_to_list/2' should be used whenever possible, especially since
+%% fate_to_list/2 should be used whenever possible, especially since
 %% transaction results are type checked by nodes at runtime.
 
 fate_to_list(Term) ->
@@ -978,7 +975,7 @@ fate_to_list(Term) ->
 
 %% @doc
 %% Print a FATE term from gmbytecode in Sophia syntax
-%% Like `fate_to_list/1', but now type information from the AACI data structure
+%% Like fate_to_list/1, but now type information from the AACI data structure
 %% can be provided, in order to correctly interpret types like records,
 %% variants, and unicode characters.  If the type information you provide is
 %% incorrect for the FATE term provided, then the function will fall back to
@@ -991,7 +988,7 @@ fate_to_list(Type, Term) ->
 
 %% @doc
 %% Print a FATE term in Sophia syntax, without concatenating
-%% The `fate_to_list/1' function builds an iolist, and then concatenates it into
+%% The fate_to_list/1 function builds an iolist, and then concatenates it into
 %% a list. If you are going to put the term into a bigger iolist directly
 %% after, or write it to a streaming device, then it can save effort and memory
 %% to just use the iolist directly.
@@ -1010,7 +1007,7 @@ fate_to_iolist(Term) ->
 
 %% @doc
 %% Print a FATE term in Sophia syntax, without concatenating
-%% Prints using type information, like `fate_to_list/2', but without spending
+%% Prints using type information, like fate_to_list/2, but without spending
 %% time or memory concatenating the result into a list, like fate_to_iolist/1.
 
 % Special case for singleton records, since they are erased during compilation.

src/hz_sup.erl

@@ -9,7 +9,7 @@
 %%% @end
 
 -module(hz_sup).
--vsn("0.9.2").
+-vsn("0.9.1").
 -behaviour(supervisor).
 -author("Craig Everett <zxq9@zxq9.com>").
 -copyright("Craig Everett <zxq9@zxq9.com>").

zomp.meta

@@ -1,10 +1,10 @@
 {name,"Hakuzaru"}.
 {type,app}.
 {modules,[]}.
-{prefix,"hz"}.
 {author,"Craig Everett"}.
+{prefix,"hz"}.
 {desc,"Gajumaru interoperation library"}.
-{package_id,{"otpr","hakuzaru",{0,9,2}}}.
+{package_id,{"otpr","hakuzaru",{0,9,1}}}.
 {deps,[{"otpr","sophia",{9,0,0}},
        {"otpr","gmserialization",{0,1,3}},
        {"otpr","gmbytecode",{3,4,1}},