[ 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: 304 KB, 1200x800, DMujtILXcAEE7ko.jpg [View same] [iqdb] [saucenao] [google]
20818216 No.20818216 [Reply] [Original]

serious discussion of the tech ONLY
no price discussion

>> No.20818245

Let me try and explain it as simply as possible. Say you write a contract that lets anyone send money to someones wallet, say, a charity. this is what it looks like

charityAddress = 0x123;

function () payable {
sendMoneyTo(charityAddress)
}

All money sent to the contract is rerouted to the charityAddress. Problem is, that charities wallet has changed in the past, and you assume in the future it might change again. If it does change, any money sent to the contract is useless, and you will need to publish a new one. So you write another bit of code instead

function changeAddress(address new) {
charityAddress = new;
}

Great, now we can change the address. Only problem is, it is on the blockchain, which means anyone can change the address, and set it to whatever they want. We don't want people to take advantage of that and scam charity money, so instead we write our own address into the contract as an owner, and put something like this in the changeAddress functions

require(msg.sender == ownerAddress);

But this just means you have a single ownerAddress who can change the address whenever they want! that's not decentralized at all! So do you have a frail, easily broken contract with no central owner? Or a centralized contract where you have to trust the single owner?

DFOs let you have the best of both worlds. You can now give voting functionality to an ownership token that allows users to vote for changes. Rather than trusting the owner of the contract, a proposal to change the charityAddress is raised, and the people vote, and the address is changed. But this doesn't even start to cover it. With DFOhub and robe you can build totally decentralized, censorship proof site than can load on any web3 browser, front end on-chain and everything.

>> No.20818281
File: 1.73 MB, 2658x1554, 1595886976694.png [View same] [iqdb] [saucenao] [google]
20818281

>> No.20818301
File: 237 KB, 676x1189, 1591661562993.png [View same] [iqdb] [saucenao] [google]
20818301

>> No.20818307

LOL JULIAN

>> No.20818371

>>20818307
poor Julian, doesn't even understand how chained NFT's and ROBE can be used to decentralize the internet

>> No.20818503

Honestly it all looks like it's the new Etheruem Diamond contract pattern as a service. Making it easy for anyone to write interchangeable pieces and making a contract completely changeable autonomously, and removing the limit of how big a contract can be.

https://eips.ethereum.org/EIPS/eip-2535

The vernacular used is garbage but it's a brilliant, yet complex structurally, idea.

less technical
https://dev.to/mudgen/ethereum-s-maximum-contract-size-limit-is-solved-with-the-diamond-standard-2189

>> No.20818635

>>20818503
I could be wrong but I think that's just an upgrade of EIP 1538, it doesn't actually address the governance problem. it adds trust rather than removes it

>> No.20819755
File: 132 KB, 893x1300, 12561973-attractive-naked-girl-with-hard-hat-isolated-on-white-background.jpg [View same] [iqdb] [saucenao] [google]
20819755

bump

>> No.20820343

Bump for Julian

>> No.20821221

>>20818216
>>20818245
is it possible to "port over" existing DAOs? or does it only allow new ones to be built?

>> No.20821246

>>20821221
you can port over DAOs but it takes some work, obviously, and would require a token swap to move to the new governance token

>> No.20821255

>>20819755
flat and barrel chested

1/10

>> No.20821653

>>20821246
ok, does DFO have any advantages for existing DAOs? im not a coder so bare with me. aside from porting over, can DFO hook into existing DAOs and offer something that improves their product?

>> No.20822039
File: 1.03 MB, 1003x1200, Q7xFZl-6.png [View same] [iqdb] [saucenao] [google]
20822039

We are so fucked.

>> No.20822070
File: 8 KB, 144x144, avatar.jpg [View same] [iqdb] [saucenao] [google]
20822070

>Julian