search

jerryfane / generative-brc-721

This repository houses the documentation for the proposed Generative BRC-721 Standard, a new concept aimed at optimizing the creation of Non-Fungible Ordinals collections within the Bitcoin ecosystem.
78 stars 13 forks source link

Deterministic images encoding and reconstruction #1

Open russanto opened 1 year ago

russanto commented 1 year ago

I would like to raise the point on the determinism of the images encoding and their reconstruction.

As it is now, the standard looks like to give freedom on the image encoding as any can be specified in the base64 string. However, JPG and PNG were not constructed with determinism in mind, so I think their adoption should be first carefully understood, as different implementation can interpret differently the format.

Similarly, the image reconstruction algorithm should be specified as it compounds with the potential ambiguity on the image encoding.

I think ending up with a standard suggestion or prescription would enhance the overall standard quality.

I am not an expert on the topic, so I may be updating this first message with more useful references while I go through them.

dennisklicker commented 1 year ago

If there's a different implementation then it's by design no longer base64, so I'm not sure I understand the issue being raised. I think we need some more verbose documentation on how to actually convert your image files into base64 but it's not because I'm worried about alternative interpretations, it should just be trivial to do for artists and creators.

russanto commented 1 year ago

The point is not on Base64, as it is merely a way to represent binary data in text, but on the image formats. JPG is a compressed format, is the algorithm to reassemble, or even to compress, them deterministic ? Is there a unique algorithm to reassemble them ? If not, should the standard specify more details on it ? Same discussion for PNG or any other format since there is no restriction on it.

If the answer to the questions is yes, then no problem, otherwise maybe the solution is to restrict or suggest some suitable for the aim, or to embed details on the algorithm, or making an inscription with the algorithm.

jerryfane commented 1 year ago

The point is not on Base64, as it is merely a way to represent binary data in text, but on the image formats. JPG is a compressed format, is the algorithm to reassemble, or even to compress, them deterministic ? Is there a unique algorithm to reassemble them ? If not, should the standard specify more details on it ? Same discussion for PNG or any other format since there is no restriction on it.

If the answer to the questions is yes, then no problem, otherwise maybe the solution is to restrict or suggest some suitable for the aim, or to embed details on the algorithm, or making an inscription with the algorithm.

Feel free to provide examples here on how that would change. I think it makes sense to provide more details on the compression and rendering of images. Not sure, but one easy nice way to do it would be to have the actual deployer decide which format, compression and rendering method to use.

russanto commented 1 year ago

I reasoned a bit about the topic. I think at the end of the day the aim is to check the integrity of the generated asset so that we know they correspond to the creator ones. Any discussion on the format/encoding/compression could bring benefit on what to suggest to use but the topic may be really deep and generate only some minor optional benefits.

So, since determinism is the key target, it could be achieved with what is already on the plate.

  1. First solution is to include the final hash of each collectible so that anyone could verify a digital asset is legitimate;
  2. Second solution is to provide on-chain data (as it already is) with an on-chain inscribed algorithm.

Option 1 was originally mandatory but was removed. Hash is obviously the best way to go for verifying integrity, but there is a missing piece about it, which I think may be in contrast with the overall ordinals philosophy: it requires knowledge which relies off-chain. As a consequence it could be a good double-check method, but I do not think it can be the main one.

So we come to option 2. If the algorithm is immutable, deterministic and executed in a deterministic environment, then the outcome can not be anything but deterministic, as well, since data is immutable, too. Generated asset can be compared with the one to test and that's it. I saw @jerryfane already deployed some algorithm to reconstruct OrdiBots. There are several advantages:

  1. Different collections can just point to the same algorithm if they want, so in practice there is just a few bytes cost given by the additional field. No additional inscriptions for basic known stuff.
  2. Collections can specify their own algorithm: maybe traits which combined obtain something different from the mere overlap.
  3. Everything is forced to be on-chain. No github repos to point to to verify assets, external links, portals, ...

So my proposal is that the reconstruction code becomes part of the standard with a dedicated field in the deploy inscription. If this a shared proposal we may want to invest a bit of time to see which is the best technical way to do it. (reproducible code build, execution environment, ...)

jerryfane commented 1 year ago

@russanto

I love this second approach. Thanks a lot for your contributions! I think it really makes sense. Once the standard reaches a more mature stage, we can inscribe an "official" (but not obligatory) deterministic renderer on-chain that anyone can use. Meanwhile, if they wish, collection creators can design their own renderers, inscribe those, and reference it as you suggested in the deploy inscription.

If this a shared proposal we may want to invest a bit of time to see which is the best technical way to do it. (reproducible code build, execution environment, ...)

Feel free to test and propose! I think this will ultimately make the entire standard much more resilient.