Do not calculate container ID in container.Put method #28

New issue

Closed

opened 2025-12-28 18:08:17 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:08:17 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (May 28, 2021).

In current implementation Container contract calculates container ID in Put method by itself.

Contract doesn't return calculated ID, so the calculation is performed on two sides at once: the calling and the contract.

I propose to add explicit argument to Put call with container identifier in order to not have a binding of the contract code for the identifier format, which can be dictated by the application logic. It will also reduce the computational load from the contract

Originally created by @cthulhu-rider on GitHub (May 28, 2021). In current implementation `Container` contract calculates container ID in `Put` method by itself. Contract doesn't return calculated ID, so the calculation is performed on two sides at once: the calling and the contract. I propose to add explicit argument to `Put` call with container identifier in order to not have a binding of the contract code for the identifier format, which can be dictated by the application logic. It will also reduce the computational load from the contract

sami

2025-12-28 18:08:17 +00:00

closed this issue
added the
enhancement

container
labels

sami commented

2025-12-28 18:08:18 +00:00

Author

Owner

@realloc commented on GitHub (May 31, 2021):

I suggest to stick with current in-contract ID calculation. Independent ID calculation is the additional guarantee of container structure correctness.

Ideally InnerRing would not modify the container structure, but only ensure its correctness and approve creation.

@realloc commented on GitHub (May 31, 2021): I suggest to stick with current in-contract ID calculation. Independent ID calculation is the additional guarantee of container structure correctness. Ideally InnerRing would not modify the container structure, but only ensure its correctness and approve creation.

sami commented

2025-12-28 18:08:18 +00:00

Author

Owner

@realloc commented on GitHub (Aug 12, 2021):

@alexvanin @cthulhu-rider I suggest closing this issue, as the current mechanism assures the correctness of the structure and let's the container creator to make sure he got onchain what he expected.

@realloc commented on GitHub (Aug 12, 2021): @alexvanin @cthulhu-rider I suggest closing this issue, as the current mechanism assures the correctness of the structure and let's the container creator to make sure he got onchain what he expected.