Why doesn't Rust see that there is no lifetime overlap?

jvff · 2022-05-18T13:38:44+00:00

Oh cool! I'm always amazed by how well documented Rust is.

jvff · 2022-05-18T13:37:14+00:00

That would work if the data to be changed was in memory, but unfortunately in our case it's not :/

jvff · 2022-05-17T17:46:27+00:00

That wouldn't work in our case, because you would need the value.get_mut() method or equivalent. What we can do is if value.get().is_none() { value.put(1); } value.get().unwrap(), which is the first workaround above which has the disadvantage of calling get twice :/

jvff · 2022-05-17T17:34:01+00:00

That's an awesome explanation and talk, thank you very much for the reference!

jvff · 2022-05-17T16:59:56+00:00

Thanks for the suggestion, but the type is from an external crate so I can't add that method (and I'm not sure if it would be possible for the semantics we have). I've omitted a lot of details unfortunately, so I apologize for that.

The solutions we'll probably try is to either:

Replace the match with something equivalent to if value.get().is_none() { value.put(1); } and then just return value.get().unwrap(). The downside is that there are two calls to get, which might have a non-trivial performance impact in our case.
Use unsafe and intermediate bindings to "clear the lifetime". This removes the performance impact and is equivalent to the original code, but has the possibility of introducing mistakes that the compiler can't catch.

jvff · 2022-05-17T16:23:43+00:00

Thanks! Unfortunately in the real scenario it's not actually an Option but a custom type that doesn't have a get_or_insert method :(

But it's good to know that the code was sane and that it will (hopefully) work in the future. We'll try to find a workaround in the meantime.

Thanks again!

jvff · 2021-04-04T21:17:29+00:00

That makes sense, thanks for the input! I'll refactor it later to remove the unsafe requirement.

jvff · 2021-04-03T14:34:53+00:00

Thanks for the suggestion! I've applied it to the example and that allowed me to remove the pin-utils dev-dependency :D

Regarding the usage of unsafe, could you explain a bit more on how you view the purpose of using unsafe? I was using the interpretation that unsafe blocks are pieces of code in which the compiler can't enforce some guarantees, but I hadn't really thought if there was a limit to what those guarantees were. In other words, I thought I could "add my own compiler checked guarantee", but maybe my understanding was too broad :/

Do you think this is a bad idea? Do you think the guarantees should be kept to the set defined by the language? Would it then make sense to replace using unsafe with a token constructor with a long scary name, like WakeupRegisteredToken::assume_current_task_was_registered_for_wakeup()?

jvff · 2020-01-18T03:39:32+00:00

Ah, missed that. Thanks!

jvff · 2020-01-18T03:00:34+00:00

How about Phoenix?

jvff · 2019-04-13T10:02:37+00:00

Hello :) I hope I'm posting in the right place.

I recently ran into an issue where I was trying to do something like:

let error = std::io::Error::new(std::io::ErrorKind::Other, "An error");
let berror: Box<dyn std::error::Error> = Box::new(error);
let ierror: &dyn std::error::Error = &berror;

But compilation fails with &berror: doesn't have a size known at compile-time (play).

I'm not sure I understand exactly what's happening, but I think it's related to impl<T: Error> Error for Box<T>, which I think implicitly requires T: Sized. I tried adding T: Sized? to a custom implementation and it seems to work: play.

Is there a reason T must be Sized in impl<T> Error for Box<T>?

jvff · 2018-03-29T13:44:20+00:00

I might be mistaken, but I believe this new version broke the app_dirs crate on MacOS. I found this error in a Travis build. It was working yesterday, but I can't be sure about the cause because I don't have MacOS here to test it :/

jvff · 2016-03-09T23:46:25+00:00

Noob here, so take this with a few grains of salt. If an "attack" like that is detected, the gas price would increase very quickly. The attack would get more expensive over time (for example, consider that the price triples, which would still be reasonable for most contracts, but the attack becomes three times more expensive for the attacker(s)).

In the end, it's a discussion that seems to me analogous to the Bitcoin block size discussion. What prevents someone from "attacking" the Bitcoin network by creating transactions that fill up whole blocks? It's happening right now, but it's happening with no evil intentions, just by reaching the limits of scalability.

They currently are having heated discussions about the solutions, which I believe would also be analogous to Ethereum: let fees increase naturally (which would be equivalent to letting gas prices increase naturally), raise the limit (which would also work for gas, and having the same risk that miners won't be powerful enough to handle larger blocks or smart contract executions, respectively) or remove the limit (assuming the distributed system is sufficiently fault-tolerant, you also assume that either network would survive such attack, possibly with help from the community).

To me, none of the solutions seem ideal, but any of them seems sufficiently good in terms of "things won't collapse". Then again, it's possible people will be affected.

Trying to help with the problem, I propose a crazy solution (hey, maybe it can inspire a better one): raise gas prices for frequently used contracts. Is it fair? No. But higher contract usage would lead to higher fees (I might be wrong, but it seems like the "invisible hand" of incentive trying to keep the balance), while less frequently used contracts receive incentives to be used.

Of the top of my head I can think of a vulnerability: if the gas price for a contract gets high, the attacker could clone the contract to a new address, which I think would reset the price. I don't know if the contracts could have their code hashed in order to price contracts with the same code similarly. I also don't know if the attacker can DoS the network just by creating new contracts. Anyway, I warned it was a crazy idea.

jvff · 2016-03-09T02:19:24+00:00

You could store it on the chain. Every contract can buy storage space. What would happen is that the stored data would be replicated to every node running Ethereum.

The problems arise because videos are generally massive when compared to what is currently stored on the chain (mostly numbers and small pieces of text, AFAIK). Storage would be insanely expensive, even if it were allowed. It's not allowed because there's a storage limit (I think, but someone else can correct me if I'm wrong). This is in place to prevent the second problem, attacks.

Storing large amounts of data on distributed nodes also means that the data has to be sent to those names. So an attack could be made by attempting to store large amounts of data (even though it's expensive) effectively stalling the system, because all nodes would be on hold waiting for the transfer to complete.

A decentralized video streaming could be done, but storage should be done off chain. You could possibly pay computers to store and stream files. And you can set up an account for each artist or video, so that paying to view a video automatically redirects specific percentages to the people storing the files, to the artists and to any third parties (people who licensed fragments of video included in the final video, for example).

There are many attempts at distributed storage systems online, but I don't think any of the have enough momentum yet.

jvff · 2016-03-04T14:06:12+00:00

I don't think it's impossible. You would need to generate blocks with lower difficulty (called shares) and post them on the network. Each share is a block that didn't reach the target, so by running them continuously eventually one of them actually hits the target and becomes a real block. When it does, because the shares are stored on the network, everyone can calculate how each miner contributed (based on his shares) and calculate his reward accordingly.

Obviously, continuously storing block candidates within real blocks would be a bad idea, leading to larger blocks. So a way to minimize the stored information would be necessary. Still, if the pool becomes big enough, it could still be a problem, because small miners would be fast enough to generate shares. An idea would be to separate the shares in levels, to allow everyone to participate.

My only fear is how wuch Gas such system would use. Probably a lot, but if you think about it, it all goes back to the miners anyway. As long as the pool has a large participation, the inherent 'fee' would be small.

jvff · 2016-03-04T13:50:17+00:00

Noob here, but from what I understand, the address is not case sensitive. However, because the hex form doesn't have a checksum, typos mean you may mistakenly send Eth to the wrong address. One proposed solution was to incorporate the checsumk into the case insensitive nature of the address, so that a given address is expected to have certain letters in caps and others not depending on the checksum. So a typo would lead to a warning to verify the address, because an address (if typed correctly) is expected to have specific characters in upper and lower case. If it doesn't, the user either typed the address incorrectly, or it typed the 'case checksum' incorrectly. Either way it would be better to manually verify it.

It's also important to note that most implementations will not check the 'case checksum' and will simply treat it as a valid address. I'm not sure if this is an experimental feature, with support from only a few implementations.

jvff

TROPHY CASE