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
How to quantify nested property on smart contract? #1
Comments
Great question!! This definitely needs to be addressed somehow, and I'm not sure of the best approach either. Create2 is an interesting idea--but I'm not sure if it changes the underlying problem--even if create2 allows us to not deploy the contract up front, we still need to know the underlying bytecode. I think the second two approaches both work, but clearly they are a little annoying to do. In fact "specific quantifier" is how we did it in some examples in the original contract spec attempt, but the Speaking of
I'd be curious how you think this approach compares! :) It would probably be the closest way to match how it's done on the client. However, I'm not sure that it solves the main issue here, which is: is it possible to do this functionality without writing new solidity? The problem with all of these is that it requires new developers to potentially audit new code. Do you agree this is the biggest issue? |
Thank you for replying!
Yes, I think this is big issue. and I feel trade-off between extensibility and security ;;) After a little thought, I think we need a more limited expression than propertyFactory. This is just example. OVM claims without propertyFactoryAn example claim
In this claim, any property don't use parameters across property.(property don't use ancestor's parameter, but use parent's parameter). Claim as JSON"parameters" defines initial parameters for Property.
Predicate Implementation
And should modify 1 line of UDC contract and data structure of Property.
I think there are more good expression, but what do you think intuitively? @ben-chain |
I think this could be a good direction, however I am a little confused by the code. For example in the last section, the line |
Sorry! My fault. That is
|
This is starting to make more sense, it definitely feels like the start of a reasonable solution. 😃 More questions--is the
suggests that it is growing, but wouldn't
prevent it from growing? Also considering other naming choices here--we are probably overusing "parameters" . Perhaps something relating to free or bound variables? Second point--in the JSON example we have:
Does this mean that FooPredicate and BarPredicate are built to understand their |
Answer 1Sorry! A line below would be more like forward_match rather than check_equality.
So, parameter array is growing.
Agree! "the parameters" seems to be bound variables for a property. Answer 2
Yes, actually I was thinking to build like that(predicate understand their inputs is the index). But finally claim was decided as Property without Codes
|
Sorry for slow response here--yes, I like A few questions about this code:
|
OK! I'll use
Yes, right. Your understanding is correct.
Sorry, mistake. I should use
Yes, I mean
Sorry that was also mistake. for example
|
Cool, makes sense! I'm curious, what's the motivation for embedding inside This is feeling like a good direction, though--I think you are right and arrays just help reuse code. As long as the |
Sorry that it's taken me this long to catch up! I like what you describe with Would something like this work? JSON Claim:
Contract:
|
Nice, I think this is a promising direction @willmeister ! @syuhei176 Curious how you would compare to an "external" As a separate note, I just thought of another example of a related use we may want: |
@willmeister Thank you for replying! I don't have idea but I believe some optimizations are possible to prevent growing array. @ben-chain I think the difference between 2 approaches are call-data size to propagate variables and number of function calls to create property. And I feel the template literal for property approach is good and simpler as the first approach. 😃 I'm also interested in the componentization of the predicate! But I'm still not sure how can challengers prove contradiction of
|
I think that this "transformer"/"evaluator" must be run before we |
The topic I wanna clarify in this issue is about predicate design. And I believe PG know the same difficulty. In short, how quantifier quantify inner properties.
Simple example.
I describe the problem using simple example below.
In this formulation, when FooPredicate(1) and FooPredicate(2) are True, claim(3) is True.
The property for client.
The claim for Universal Adjudicator contract.
let's say, now Alice called
claimProperty
with b=5.Anyone can prove contradiction showing "FooPredicate(1) is False". Let's say Bob prove contradiction.
Bob should send the claim like below. It means
bb
must be less than 5, but isn't constant value.Problem
bb
in claim is not constant value but variable. So we should express variable inside innerProperty.And LessThanQuantifier should verify
bb
which is used in "innerProperty" is less than upperBound.note: quantify was called from FOR_ALL_SUCH_THAT.quantify, and FOR_ALL_SUCH_THAT.quantify was called from verifyImplication.
If we implement LessThanQuantifier,
quantify
should checkSolutions?
I'm looking for appropriate solution for this. these are my very rough ideas but I have no concrete solutions yet.
Are there any ways to make innerProperty the function returning property?
Can we use create2?
innerProperty is reducer?
Specific quantifier?
The text was updated successfully, but these errors were encountered: