You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spawning/transferring an azimuth point currently costs tens of USD. Some of that gas[1] goes to keeping the pointsownedby mapping up-to-date. If we imagine all 4 billion points being spawned, that's quite a lot of value. (even just moving all 65k stars onto Layer 2 will cost a good chunk of change.)
It seems that the only use for this mapping is the balanceOf function in the ecliptic's ERC721 interface. I doubt that's called by any contract, or ever really will be. It doesn't seem that useful. It's probably called lots by off-chain clients (token trackers and wallets). I propose that we either (a) abandon the ERC721 interface; or (b) return balance=0, and let those clients just be wrong; or (c) implement balanceOf by iterating through all 4 billion points and counting how many have owners that match the given address. This would be slow, but it's better for off-chain clients to be slow for a cosmetic function than for on-chain contracts to be charged gas for essential functions.
[1] I don't know what proportion, but someone could and should estimate it.
The text was updated successfully, but these errors were encountered:
On Tue, Oct 26, 2021, 20:28 Adam Bliss ***@***.***> wrote:
Spawning/transferring an azimuth point currently costs tens of USD. Some
of that gas[1] goes to keeping the pointsownedby mapping up-to-date. If
we imagine all 4 billion points being spawned, that's quite a lot of value.
(even just moving all 65k stars onto Layer 2 will cost a good chunk of
change.)
It seems that the only use for this mapping is the balanceOf function in
the ecliptic's ERC721 interface. I doubt that's called by any contract, or
ever really will be. It doesn't seem that useful. It's probably called lots
by off-chain clients (token trackers and wallets). I propose that we either
(a) abandon the ERC721 interface; or (b) return balance=0, and let those
clients just be wrong; or (c) implement balanceOf by iterating through all
4 billion points and counting how many have owners that match the given
address. This would be slow, but it's better for off-chain clients to be
slow for a cosmetic function than for on-chain contracts to be charged gas
for essential functions.
[1] I don't know what proportion, but someone could and should estimate it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#50>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKLYGAWF2IJJTFUFQNFLPLUI5ISHANCNFSM5GZECMQQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
Spawning/transferring an azimuth point currently costs tens of USD. Some of that gas[1] goes to keeping the
pointsownedby
mapping up-to-date. If we imagine all 4 billion points being spawned, that's quite a lot of value. (even just moving all 65k stars onto Layer 2 will cost a good chunk of change.)It seems that the only use for this mapping is the
balanceOf
function in the ecliptic's ERC721 interface. I doubt that's called by any contract, or ever really will be. It doesn't seem that useful. It's probably called lots by off-chain clients (token trackers and wallets). I propose that we either (a) abandon the ERC721 interface; or (b) return balance=0, and let those clients just be wrong; or (c) implement balanceOf by iterating through all 4 billion points and counting how many have owners that match the given address. This would be slow, but it's better for off-chain clients to be slow for a cosmetic function than for on-chain contracts to be charged gas for essential functions.[1] I don't know what proportion, but someone could and should estimate it.
The text was updated successfully, but these errors were encountered: