Can't interpret contract MPTree in returned POI
Expected Behavior
POI in the case described below should contain a complete contract tree of a single contract address mapped to it's entry without extra keys/data.
Actual Behavior
pi_+QS9PAH5Agj5AgWgLTKha2G59WNpjU2qOeEP9n/k6VUZw6lrwd2jn0zjyZb5AeH4dKAtMqFrYbn1Y2mNTao54Q/2f+TpVRnDqWvB3aOfTOPJlvhRgKBy/g6a1aHG5CUcExd2PvF/VDFQoFXDYRynvBxhsviPWoCAgKDmsQ/HT1KkP6IZIZxPre8pPevMUitDJ/wdFSLdSx2GU4CAgICAgICAgICA+HSgcv4OmtWhxuQlHBMXdj7xf1QxUKBVw2Ecp7wcYbL4j1r4UYCAgICAgICAoIEfDDawnsjhRHiZ3cH3w1bwZCU/ComV5UZ35oNfBZQNgICAgKC1oTen+OePzzEwr98V96QpzGPnNdq33nRolIwWZ31TO4CAgPhSoIEfDDawnsjhRHiZ3cH3w1bwZCU/ComV5UZ35oNfBZQN8KAgy4vNCNXy3SL07CeWTpNXmqxcXKgpwiS5xqMVvJqPbI7NCgEAiQVrx14tYxAAA/hLoLWhN6f454/PMTCv3xX3pCnMY+c12rfedGiUjBZnfVM76aAg+T20wFXy2ZOEIKWCVNexp+1QmgXSfwzarLhs8ov8rofGCgEAggPo+FKg5rEPx09SpD+iGSGcT63vKT3rzFIrQyf8HRUi3UsdhlPwoD1xbWafWKm2OCnVvDaJX/R46dFWXDVp0Dio4Am/Aa/Zjs0KAQCJBWvHXi1jD/wV4+KgkuUqD84mdniErJPs5b5pR5faMyeuAuGSpTK0rUbGowvAwPkChvkCg6B2jPRZng8uvSIogeA13/PJ3kppJyDm8hrp5NaP39/v3/kCX/hEoBHlmqYc8k9c2eNzc9JAADb3fErCVaOf2zDNbvn+WTd14hCgcz/+U+Q3icmxZXQLRTSUTLW827c3lKJfOCBYgXAEomP4O6BYJ4U3UbSFRNdKow3ApDqnzTNUNG7kE2T287Q+JQSb4NmFxCCCLwCDwiA/gICAgICAgICAgICAgICA+NWgbusUs5OcObuVt7pByi05w+imTwelvFFKINZcKb9uzA34soCgEeWaphzyT1zZ43Nz0kAANvd8SsJVo5/bMM1u+f5ZN3WAgICAgICAgICAgICAgLiA+H4oAaEBXXFtZp9YqbY4KdW8Nolf9Hjp0VZcNWnQOKjgCb8Br9mDBQADuE74TEYDoOHfv3ueq4IcJKbTzxq+A6KqCONqtFC+IRgBer5iV6BZwKCN/oB4IJIANwEHBwEBAI4vARGAeCCSGWdldEFyZ4IvAIU3LjAuMQCAAcCCA+j4U6BzP/5T5DeJybFldAtFNJRMtbzbtzeUol84IFiBcASiY/Gg+834Gf8ycAnGZdS3wlaPv5tIpbWL68KqCphOqokQveuAgICAgICAgICAgICAgIAA+Gagdoz0WZ4PLr0iKIHgNd/zyd5KaScg5vIa6eTWj9/f79/4Q6EAHfk9tMBV8tmThCClglTXsaftUJoF0n8M2qy4bPKL/K6gbusUs5OcObuVt7pByi05w+imTwelvFFKINZcKb9uzA34RqD7zfgZ/zJwCcZl1LfCVo+/m0iltYvrwqoKmE6qiRC96+SCAACgWCeFN1G0hUTXSqMNwKQ6p80zVDRu5BNk9vO0PiUEm+DAwLP4mdE=
[
"768cf4599e0f2ebd222881e035dff3c9de4a692720e6f21ae9e4d68fdfdfefdf", // root hash
[
[
"11e59aa61cf24f5cd9e37373d2400036f77c4ac255a39fdb30cd6ef9fe593775", // extension
[
"10",
"733ffe53e43789c9b165740b4534944cb5bcdbb73794a25f382058817004a263"
]
],
[
"5827853751b48544d74aa30dc0a43aa7cd3354346ee41364f6f3b43e25049be0", // branch
[
"c420822f00", // shouldn't this and below have length of a hash?
"c2203f",
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{}
]
],
[
"6eeb14b3939c39bb95b7ba41ca2d39c3e8a64f07a5bc514a20d65c29bf6ecc0d", // branch
[
{},
"11e59aa61cf24f5cd9e37373d2400036f77c4ac255a39fdb30cd6ef9fe593775",
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
// contract entry
"f87e2801a1015d716d669f58a9b63829d5bc36895ff478e9d1565c3569d038a8e009bf01afd983050003b84ef84c4603a0e1dfbf7b9eab821c24a6d3cf1abe03a2aa08e36ab450be2118017abe6257a059c0a08dfe8078209200370107070101008e2f01118078209219676574417267822f0085372e302e31008001c08203e8"
]
],
[
"733ffe53e43789c9b165740b4534944cb5bcdbb73794a25f382058817004a263", // branch
[
"fbcdf819ff327009c665d4b7c2568fbf9b48a5b58bebc2aa0a984eaa8910bdeb",
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
{},
"00" // can't find documentation for this value
]
],
[
"768cf4599e0f2ebd222881e035dff3c9de4a692720e6f21ae9e4d68fdfdfefdf", // extension
[
"001df93db4c055f2d9938420a58254d7b1a7ed509a05d27f0cdaacb86cf28bfcae",
"6eeb14b3939c39bb95b7ba41ca2d39c3e8a64f07a5bc514a20d65c29bf6ecc0d"
]
],
[
"fbcdf819ff327009c665d4b7c2568fbf9b48a5b58bebc2aa0a984eaa8910bdeb", // extension
[
"0000",
"5827853751b48544d74aa30dc0a43aa7cd3354346ee41364f6f3b43e25049be0"
]
]
]
]
In this tree I'm finding:
[
[
// contract address, ct_ECdrEy2NJKq3qK3xraPtcDP7vfdi56SQXYAH3bVVSTmpqpYyW
'1df93db4c055f2d9938420a58254d7b1a7ed509a05d27f0cdaacb86cf28bfcae',
// contract entry
<Buffer f8 7e 28 01 a1 01 5d 71 6d 66 9f 58 a9 b6 38 29 d5 bc 36 89 5f f4 78 e9 d1 56 5c 35 69 d0 38 a8 e0 09 bf 01 af d9 83 05 00 03 b8 4e f8 4c 46 03 a0 e1 ... 78 more bytes>
],
[
// contract address . 0x10 ?
'1df93db4c055f2d9938420a58254d7b1a7ed509a05d27f0cdaacb86cf28bfcae10',
// can't find documentation for this value
<Buffer 00>
]
]
So, the meaning of a second value is unclear, the same as branch that contains values with lengths not equal to hash length.
I'm not sure that I understand https://github.com/aeternity/protocol/blob/master/serializations.md#proof-of-inclusion-on-state-trees-poi--poi correctly.
Steps to Reproduce the Problem
- Open state channel
- Deploy a contract
- Request POI for both peer addresses and the contract
- Check the contents of POI
const poi = 'pi_...';
Buffer.prototype.toJSON = function () { return this.toString('hex') };
console.log(JSON.stringify(
require('rlp').decode(require('@aeternity/aepp-sdk').decode(poi))[5][0],
null,
2,
));
Configuration, logs, error output, etc.
I've used integration tests setup in https://github.com/aeternity/aepp-sdk-js
Specifications
- Virtualization: docker container
- OS: macOS
- Node Version: 6.7.0
The contract PoI contains the full contract information, including the contract state/store if I remember correctly.
-define(STORE_PREFIX, <<16:8/integer-unsigned-unit:1>>). - should explain the 0x10 you saw 🤔
Depending on the use-case it might be ok to ignore the contract store part...
Depending on the use-case it might be ok to ignore the contract store part
On sdk side, I just need to decode/encode it accurately.
The last question is 5827853751b48544d74aa30dc0a43aa7cd3354346ee41364f6f3b43e25049be0 node. It doesn't looks like a valid Merkle Patricia Tree node. It is stored also with a prefix to contract address.