Verified Merges: Using a certified validator to ensure a merge is accurate

[JustMaier]

To deal with concerns around licenses and visibility into what a merge might contain, I'd propose a sort of Verified Merge service that uses asymmetric cryptography with a trusted validator that essentially signs that a merge is what it says it is. Here's how it works:

Process

1. Validator is setup in merge client
2. Merge client performs merge steps and tracks steps alongside each resulting merge
3. Upon completion, merge steps are sent to validator to perform the recipe and ensure hash alignment
4. Upon full hash match, validator signs the final SHA256 hash and returns the result

Result

const result = {
  version: 1,
  validator: {
    name: 'civitai',
    key: 'publickey of verifying source', // Included here, but can/should be fetched from the validator origin
    origin: 'https://validator.civitai.com',
  },
  steps: [{
    // ...something that describes the merge applied
    resultHash: 'SHA256 of the result'
  }],
  validation: {
    algorithm: 'SHA256',
    hash: 'SHA256 Hash',
    signedHash: 'hash encrypted by validator private key',
    date: 'ISODate'
  }
}

[JustMaier]

This was brought to my attention as a way to display merge info:
https://terrastruct.com/blog/post/diagram-layout-engines-crossing-minimization/

[alixander]

saw this in my notifications as i have one for mentions of terrastruct. i'm curious what you're trying to do, anything i can help with?

[JustMaier]

Woah, cool! Thanks for reaching out. I'm not sure what you could help with here, but here's some more context so you can decide for yourself 👍

Stable Diffusion uses AI models to generate images based on text and image prompts. These AI models can continue to be trained on new datasets and merged together at specific ratios or even by specific blocks of the model. Merging has become a very popular way to create the best models as its a fast way to bring together the best parts of various models. Due to the beginning of licensed models with restrictions on their uses that extends to derivative models (merges), It's become clear that there needs to be some way to know the contents of a merge so that we can show exactly what models were used and what licenses a merge model must carry.

Unfortunately, the act of merging changes the underlying data in such a way that it's not possible to determine this by examining the file contents. However, in the process of training licensed models, it's typical for a creator to embed secret tokens that they can use to identify if their model is being used. This can then be used at a later date to determine if a model is a derivative of their work. Unfortunately, this only provides a way for the creator to make a claim on the model and not a feasible way to assess "how much" of their model remains in the merged/derivative model.

So, to try and provide a way to track and prove exactly what is in a merge, I proposed this idea of a "merge validator", that would take the steps as tracked by model merging tools (the recipe) and reproduce them and see if the resulting model matches what the creator provided. If it did, then we could use the merge "recipe" to determine how much of each model is present in the merge model and offer royalties on licensed models accordingly.

So how did Terrastruct come up... https://github.com/Janca brought it to my attention as a tool that might potentially be used to show a model's merge lineage. Since merge models typically include other merge models, visualizing those relationships could be helpful/interesting to people trying to understand the content of a model.

[alixander]

@JustMaier thanks for that clear explanation.

Is one generation a merge between 2 models? Or N?

What's the typical number of generations? O(10), 100, 1000+?

What's the unique identifier that's relevant for each "node" in a visualization? E.g. truncated token + author name?

[JustMaier]

Is one generation a merge between 2 models? Or N?

Yes, it's between 2 models

What's the typical number of generations? O(10), 100, 1000+?

Typical is 10, but in some cases, it can be as many as 50.

What's the unique identifier that's relevant for each "node" in a visualization? E.g. truncated token + author name?

The trend for identifying a model seems to be a SHA256 hash truncated to 10 characters. That identifier can then be used against a model repository like ours to grab additional information about the model.

[alixander]

Gotcha, sounds like a normal family tree then.

And is this something you want to be generated entirely with Typescript (e.g. generating the visualization client-side)? Or is calling out to an executable which outputs an SVG okay?

D2 has a powerful API to allow this sort of thing to programmatically make diagrams: https://terrastruct.com/blog/post/generate-diagrams-programmatically/

But D2 is written in Go, so calls to the library would be through Go. We have a WASM build ongoing as well, but it's not complete yet. The only other way would probably be for the CLI to accept a JSON of metadata to generate this.