Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add union type and null to SSZ #893

Merged
merged 14 commits into from May 7, 2019
Merged

Add union type and null to SSZ #893

merged 14 commits into from May 7, 2019

Conversation

dankrad
Copy link
Contributor

@dankrad dankrad commented Apr 10, 2019

This is a suggestion to add an option type and a null type to the SSZ spec. While we will not use it in the spec at the moment, this could be a very simple addition that would make SSZ much more powerful.

In a discussion with @mslipper it transpired that this was one of the main stumbling blocks for making more extensive use of SSZ in the networking. I wonder if this would solve the main problems?

@dankrad dankrad changed the title Add option type and null Add option type and null to SSZ Apr 10, 2019
specs/simple-serialize.md Show resolved Hide resolved
specs/simple-serialize.md Outdated Show resolved Hide resolved
@dankrad dankrad changed the title Add option type and null to SSZ Add union type and null to SSZ Apr 11, 2019
@snario
Copy link

snario commented Apr 12, 2019

Hi there! I’m just commenting to make a point that in state channels we need to have a single data type to represent the state in the channel and we need it to be of dynamic length. Also we need this to be in solidity early as possible

@JustinDrake JustinDrake added the scope:SSZ Simple Serialize label Apr 14, 2019
@mslipper
Copy link
Contributor

This would solve some of the issues in the networking spec, but not all of them. While we can now represent nullable values (which would clean up some of the data structures in the networking spec), it doesn't solve the problem of needing to know an upfront schema to serialize/deserialize SSZ-encoded data. For things like the RPC wrapper, we need a serialization scheme that can model something similar to generics in object-oriented languages. Right now, the easiest way to do this is to not use any serialization scheme for the RPC wrapper and instead just prepend bytes to whatever SSZ-encoded object is being sent.

Since the introduction of a null type helps us clean up data structures elsewhere, I'd still like to merge this.

@dankrad
Copy link
Contributor Author

dankrad commented Apr 16, 2019

For things like the RPC wrapper, we need a serialization scheme that can model something similar to generics in object-oriented languages.

Would it not be possible to do this using the Union type? If the call can take typs A, B, C or D, you can do this bye defining a union type of Union(A, B, C, D) and defining your RPC call on that. The type index also makes it easy to add more types to the union later without breaking compatibility with the old type.

@mslipper
Copy link
Contributor

Would it not be possible to do this using the Union type? If the call can take typs A, B, C or D, you can do this bye defining a union type of Union(A, B, C, D) and defining your RPC call on that. The type index also makes it easy to add more types to the union later without breaking compatibility with the old type.

This is possible, but unwieldy - there are something like 7 different types that the RPC wrapper can include in the request/response body field. Defining a union type on all of them seems error-prone and difficult to maintain.

@dankrad
Copy link
Contributor Author

dankrad commented Apr 17, 2019

@JustinDrake @vbuterin I am not sure if you think this is a strong enough endorsement to merge this change. I would be in favour of it as it is fairly simple and will not change anything in the consensus layer, but I don't feel very strongly either way.

@djrtwo
Copy link
Contributor

djrtwo commented Apr 17, 2019

Should we discuss this on tomorrow's call?

@dankrad
Copy link
Contributor Author

dankrad commented Apr 17, 2019

Should we discuss this on tomorrow's call?

Sounds like a good idea

@Nashatyrev
Copy link
Member

Don't we need to adjust 'fixed/variable-size' definition?
I believe we should treat the union as a variable-size type
Should we treat the union of fixed-size types of the same size as fixed-type?

@dankrad
Copy link
Contributor Author

dankrad commented Apr 19, 2019

Don't we need to adjust 'fixed/variable-size' definition?

I think it is already correct?

I believe we should treat the union as a variable-size type

Yes.

Should we treat the union of fixed-size types of the same size as fixed-type?

Hmm, I can see that, but not sure if it would be hugely beneficial to add this special case. I can see it would simplify things if we say that a union of several fixed-size object has the (fixed) size of the max size of those objects.

@Nashatyrev
Copy link
Member

I believe we should treat the union as a variable-size type

Yes.

We recursively define "variable-size" types to be lists and all types that contains a variable-size type. All other types are said to be "fixed-size"
According to this statement a union of fixed-size types is itself fixed-size. Am I missing something?

@dankrad
Copy link
Contributor Author

dankrad commented Apr 20, 2019

According to this statement a union of fixed-size types is itself fixed-size. Am I missing something?

Ah, yes, I overlooked that sentence. Fixed now.

@JustinDrake
Copy link
Collaborator

Can we alias null to {} to avoid creating a new type?

@dankrad
Copy link
Contributor Author

dankrad commented Apr 20, 2019

Can we alias null to {} to avoid creating a new type?

You mean the empty container? That sounds like an interesting idea.

@JustinDrake
Copy link
Collaborator

You mean the empty container?

Yes

@dankrad
Copy link
Contributor Author

dankrad commented Apr 27, 2019

Can we alias null to {} to avoid creating a new type?

Done.

specs/simple-serialize.md Outdated Show resolved Hide resolved
specs/simple-serialize.md Outdated Show resolved Hide resolved
specs/simple-serialize.md Outdated Show resolved Hide resolved
@@ -97,6 +113,16 @@ fixed_parts = [part if part != None else variable_offsets[i] for i, part in enum
return b"".join(fixed_parts + variable_parts)
```

If `value` is an union type:

Define value as an object that has properties `value.value` with the contained value, and `value.type_index` which indexes the type.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO maybe too many "value"s in these sentences and code. Perhaps using value.contained_value would be more readable?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we use object instead? (That's what these things are after all, objects.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean value.object or object.value @JustinDrake ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking object.value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to go with that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh but 'object' is a type in python :(

hwwhww and others added 4 commits May 1, 2019 12:39
Co-Authored-By: dankrad <dankrad@ethereum.org>
Co-Authored-By: dankrad <dankrad@ethereum.org>
Co-Authored-By: dankrad <dankrad@ethereum.org>
@dankrad dankrad requested a review from JustinDrake May 7, 2019 17:33
@dankrad dankrad merged commit b970962 into dev May 7, 2019
@hwwhww hwwhww deleted the dankrad-patch-3 branch May 9, 2019 07:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope:SSZ Simple Serialize
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants