[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/biz/ - Business & Finance

View post   
File: 19 KB, 648x648, 9c7f5a80-65c7-11e9-85cf-2f1eb28e2c89.png [View same] [iqdb] [saucenao] [google]
15901780 No.15901780 [Reply] [Original]

>Composability example 6: oracles

>Synchronous cross-shard transactions are not supported, and so the “call a contract and immediately see what the answer is” workflow would NOT work. Instead, however, you could simply provide a Merkle proof showing the value in the state of the contract on the other side in the previous block (or in the most recent block for which the application’s shard is aware of the oracle contract’s shard’s state root).

What does this mean for pic related?

>> No.15901794
File: 445 KB, 594x597, Coffee.png [View same] [iqdb] [saucenao] [google]
15901794

>>15901780
Compost these nuts

>> No.15901803

It’s like a variable in a previous block that points to an answer that may or may not be solved yet. Almost like a map/placeholder that leads to the answer so when it’s ready, it can be accessed.

Kinda like a promise or callbacks but not really, but similar.

>> No.15901819

I guess it relates to an app on one ETH2.0 shard trying to call the state of a smart contract on a different shard, and difficulties with getting synchronicity across the two shards.
The technical challenges of making this all work while the EVM is being completely restructured is an absolute mindfuck. The people doing this are unbelievably brilliant.

>> No.15901851
File: 111 KB, 640x640, 1570902951819.jpg [View same] [iqdb] [saucenao] [google]
15901851

>>15901819
Two trannys, 3 furries, and a white ETHiopian.
>doubt

>> No.15901896

>>15901803
So it's asynchronous. But what does this mean for the flow of communication between a consumer and an oracle on another shard?

It can not be instant by definition and how much overhead will it cause?

>> No.15901974

>>15901896
I think the over head is up to whatever the data is being retrieved from and then how long it takes to be verified by whatever verification steps that is whether it’s being mined or deemed legitimate by other oracles giving the same data.

As for the flow of communication, I’m really not sure. Whatever is closest to the blockchain layer will likely receive it first but who knows.
If the consumer presses a button for a contract which requires an Oracle call and the oracle call has to use an external adapter which then needs to be processed by whatever API is being used then I’d say it’s likely the consumer is on the butt end in both input and output scenarios.

Not sure if that’s what you were asking tho.

>> No.15902028

>>15901974
I'm thinking about the overhead in interactions between a consuming smart contract and an oracle smart contract on another shard. Whether or not it will be significant or not.

Eg. a user triggers a consuming contract that depends on an oracle to execute, so we have to wait for some cross-chard async things.

There will of course be a varying latency for each service an oracle can provide. The reference data points however are updated in a certain interval, so the "granularity" of the data are set beforehand and they're fundamentally not instant.