- May 2022
-
community.optimism.io community.optimism.io
-
This directly rewards community members for the positive impact of their work.
How can we ensure this statement is true? (This statement would obviously be false if the Citizens' House went byzantine, for lack of a better term.)
-
This creates strong incentives for individuals to build for the public good of the Optimism Collective.
IMNHO, this is only true if it's clear to people in advance how they will get paid. I think RetroPGF is a great idea, but we have to be careful about what it will mutate into in the context of a firm.
-
Optimism takes a step forward, by building a sustainable funding source into the mechanisms of the network itself.
What's actually being constructed is a new type of firm. (Again this will be important below.)
-
the right to blockspace is the sustainable source of revenue that drives OP’s economic model and grows with the network itself. #
I think this is appropriate for this document but strictly speaking false and is in some sense the root of all my other critiques.
Bitcoin's value proposition is "alegal payment" Ethereum's value proposition is, ultimately, "unstoppable computation" (there are some caveats but let's ignore those for the time being.)
It seems to me that ultimately Optimism's value proposition is, "we work really hard to provide a high-availability aggregation/tx-batching service for existing Ethereum Dapps and their users" The reason Optimism block space is valuable is because it allows for Ethereum derived security at lower total costs.
I'll explain why this is all important in further comments.
-
- Feb 2020
-
github.com github.com
-
trusted timestamps
blockchain block hashes are trusted timestamps... but yes, this protocol is better than that.
-
Revoking a device requires a trusted root authority, which is the Identity Key. This approach is required because if any device were allowed to revoke another it would not be possible to know which devices remain under the control of the Identity owner and which have been compromised. An attacker might revoke all the non-compromised devices and thereby take over the Identity.
if a user controls multiple devices they can quarantine a device from one device, or mark it suspect, then use all of their other devices to vote it out. I only mention this because this is what would be required to have the constraints make sense. Having a single primary device is much easier I think. and then just use social key revocation if that device is lost.
-
a device publishes the Device Certification Messages for all its siblings
I think this is a good MVP protocol. It's not a good protocol for production.
-
Devices form a certification DAG with the Identity Key as its root.
This explicitly disagrees with the constraints and makes a lot more sense.
-
Bot Identity Keys are created by the host Bot Container during Bot Instance creation and are securely stored within the container environment for the lifetime of the Bot Instance.
What happens when this invariant varies?
-
Interactive users create their Identity Key during initial onboarding: "Create New Identity". After initially signing certification messages that assert the user's name, and authorize the local device (see device keys below), the Identity Private Key is not retained. It must however be saved as a paper key or word phrase, or in a secure hardware token for potential later use in device revocation.
This doesn't sound quite right to me, it seems like we are trying to side-step "the model requires a primary device", It's very difficult to reason about MVP key/device management protocols.
-
Joining a new party requires user action on only one device. Other devices can automatically join without user intervention. (Each device may be configured by the user to only replicate a subset of parties).
If I add a party on device A, how do I get information about that party to Device B? These constraints are confused. Where is the nexus of control that allows a user to define which devices automatically join parties? There is an implicit assumption of a primary device, which is what's so confusing about these constraints.
-
a user's devices operate under a single identity for the purposes of access control in a party.
But there may also be an identity per party, so somehow the devices need to non-interactively discover parties that other devices have joined? Sounds like magic.
-
The device provisioning process is one-step (once provisioned a new device is admitted to all current parties).
Calling this one step is misleading because it must be an interactive process.
Also this means sending an update to every entity in every party every time an identity does device management, which sounds more like a DoS vector than a feature.
This also exposes that much of the complexity in this system is around device management as a very concrete proxy for key management. So one device can have many keys, but a single key can only ever be on one device, this means we need some fairly sophisticated Distributed Key Generation (DKG) Something like this: https://www.sciencedirect.com/science/article/pii/S0304397516001626
-
Private keys are never exchanged across devices. Devices must be revocable, with other nodes able to determine which feeds and messages from a revoked node should still be considered valid, dating from prior to revocation.
These together seem to invalidate 2. It's the set of private keys across the set of devices on which the identity exists, not a single key. 8 makes this distinction more clear.
-
Each device needs to have only its own Device Key and keys for its local feeds. No need to have a master key available on devices for normal operation.
Power users will want to use a hardware key and to manually add each device into a party. That being said, I appreciate the UX tension here.
-
which cannot be changed.
Why not just make the history easy to access?
-
An identity is secured by a private key (which has a recovery mnemonic), which is used as the root of trust.
Could be more clear.
-
- Jun 2016
-
blog.ethereum.org blog.ethereum.org
-
the smart ones already know and appreciate these issues
Great, so you will be leveraging their intelligence by integrating their work into Ethereum?
-
intent is fundamentally complex.
While I agree there is a fundamental complexity to intent, I don't think that actually applies here.
I see the most significant issue being a non-application of well known and well researched solutions to the problems Ethereum faces. Type-checking by consensus solves the vast majority of these intent issues.
-
there will not be a single magic technology that solves everything.
All of these issue can be solved via correct and holistic design of the VM, compiler and language. As demonstrated by other existing systems.
-
Taking on the project of experimenting with different smart contract programming languages, as well as formal verification and symbolic execution tools
There is a lot of existing research in this field, we should take a systematic approach toward integrating it into Ethereum.
-
Formal verification
How do you suggest the EF support this work? Given the existing CALL semantics we know the utility of formal verification is limited.
-
Standardization of as many components as possible
Standardization and inclusion into the blockchain.
-
any checks or highlights should not just exist at the level of the development environment, they should also exist at the level of block explorers and other tools where independent observers can verify the source code.
These need to be validated via consensus. Anything less is a manifestation of cognitive dissonance on the part of the protocol designers.
-
One simple use case is as a way of proving termination, greatly mitigating gas-related issues. Another use case is proving specific properties – for example, “if all participants collude, they can get their money out in all cases”, or “if you send your tokens A to this contract, you are guaranteed to either get the amount of token B that you want or be able to fully refund yourself”. Or “this contract fits into a restricted subset of Solidity that makes re-entrancy, gas issues and call stack issues impossible”.
My intuition is that to do with stuff without functional language properties is extremely impractical. Adding these at the solidity language level, by providing a functional language seems like the optimal path. Gas and other EVM warts would need to be addressed to make this viable.
-
having a generic one seems like a very valuable idea.
This is exactly what type systems are for.
-
we may want to discourage every casino from creating its own random number generator, and instead direct people to RANDAO (or something like my RANDAO++ proposal, once implemented).
Yes, these should be native contracts.
-
- Dec 2014
-
justinetunney.com justinetunney.com
-
Hard labour such as this will also help cleanse them of their bourgeois mindset. The first rule of revolution is to purge all counter-revolutionary tendencies. We can’t have the engineers thinking that such menial chores are beneath them. We must also ensure that, under no circumstances, will our engineers be inclined to delegate their chore duties to the poorer oppressed classes of society (that we fired earlier). So now we’ve got a hippie egalitarian software company, consisting solely of engineers of roughly equal intelligence, who share the toil of grunt work equally. The unequals have been loosed to a secluded slum so they’ll be of no use to society. The cops will keep the unemployed lumpenproles at bay, for their very sight will engender in us feelings of cognitive dissonance that’d threaten our new reality of mythical equality. Except now it turns out that our decision to go egalitarian was very bad for business. Getting rid of the janitors and CSRs making $50k/year saved us a lot of money, and software engineers only cost $100k/year which isn’t that much more… Oh but wait, it turns out that if we look at this balance sheet thing, each engineer’s labour created $1,200k/year2 in profits for the company. Now that they’re spending half their time doing grunt work, profits per engineer has declined to $600k/year. That’s a big dip. So we need to double our engineering staff if we want to sustain our growth trajectory and monetise our assets. We might also need to make compromises on the quality of engineers we recruit in order to fill this void quickly. But wait, it turns out we’re actually exploiting our engineers because that $500k/year in surplus value extracted from their labour is going to the owners of the company. That’s not very equal, especially since the owners aren’t actually producing software. So to maintain the egalitarian myth, we must become a cooperative and pay each engineer a salary of $600k/year. Thus, we have communism.
LOL. So this is farcical writing, right? It reads like you got tired of making pretend points and just went for sensational storytelling.
-
Therefore we must force the software engineers to scrub toilets and answer phone calls. There really isn’t any other solution. But this introduces another problem, because software engineers tend to avoid that sort of work like the plague. But thankfully, there’s another really good egalitarian antidote to this problem: distribute the toil equally amongst everyone. Each engineer would be issued a chore schedule at the beginning of the month. It would regiment their lives by itemising all the things they need to do. Things like: one hour on Thursdays and Fridays cleaning bathrooms; Mondays answering phone calls from customers; Tuesdays and Wednesdays writing code; etc.
This is nonsense. The most significant problems being:
- It's so cost ineffective that the company couldn't be competitive.
- The variance in SWEs' ability to do chores would ensure a significant number of the tasks would be done unsatisfactorily.
-
So why should the janitor, who’s unable to write code, be paid the same as the software engineers who can?
The only rational people who suggest janitors be paid the same as engineers are criminals. If the USSR actually worked this way, which I have never bothered to independently confirm, that's because the USSR was being run by criminals.
-
Therefore we’ll need to fire all the janitors and customer service representatives, since they don’t meet the SWE intelligence bar. Now we could technically change our definition of “equality” to simply mean “equal pay”. But then the software engineers would be pissed off that they’re getting paid the same as the janitors.
None of this make any sense. Why would you need to fire the janitors? To alter the distribution of intelligence in the company? You can't just subcontract janitorial services, like what most real-life businesses do anyway?
Also, the simple solution to this problem is to make base pay that of a janitor and "bonus" pay based on metrics related to actually writing, supporting, and operating software.
-
we’ll need to exclude people who fall outside one standard deviation of the software engineer IQ bell curve.
You really do a poor job of supporting this position.
-
where intelligence is the only metric we care about
On what authority did you decide this was true? Because you don't really justify this statement, which is again, integral to your argument, it is difficult to make any direct counterarguments. Having studied Psychology, I am skeptical that there is any research to support such a coarse-grained position.
-
They have what Marx would call a dialectical relationship.
Citation? I have not studied Marx in a significant way, but I question of he would agree with the subdivision of labor you are arguing for for further down the page.
-
egalitarianism
Which one of these definitions are you referring to? http://en.wikipedia.org/wiki/Egalitarianism
-
Diversity
Do you mean one of these definitions? http://en.wikipedia.org/wiki/Diversity#Sociology.2C_politics_and_law
Or one of these definitions? http://en.wikipedia.org/wiki/Diversity#Business
It is unclear from the rest of the article what is you're talking about exactly.
-
Diversity and egalitarianism are fundamentally incompatible.
Since this is in many regards the crux of your argument, it would be if you took some time supporting it, ideally with citations.
-
Our technocratic overlords extract surplus value from our labour and force us to work long hours.
Agreed.
-